I have loaded an "arial.ttf" file (taken from my /Windows/Fonts folder) into memory, however passing this into FT_New_Memory_Face crashes (somewhere in FT_Open_Face). I am not able to debug this, any clues as to what I might be doing wrong?
unsigned char *fontBuffer = LoadFile("arial.ttf");
zip_uint64_t fSize = GetFileSize("arial.ttf");
FT_Library library; /* handle to library */
FT_Face face;
int error = FT_Init_FreeType( &library );
if( error != 0 )
printf("FT_Init_FreeType failed");
error = FT_New_Memory_Face( library,
(FT_Byte*)fontBuffer,
fSize,
0,
&face );
It turns out the problem was on my end, particularly, the LoadFile method was returning memory from the stack, rather than the heap. The library works fine. Thanks!
I searched for the answer for 1 day. The problem was in note section.
https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_New_Memory_Face
You must not deallocate the memory before calling FT_Done_Face.
FreeType don't copying buffer and uses pointer that you send to FT_New_Memory_Face
Related
I'm running a firmware simulation in a DLL which has simulated NAND (256MB or 1GB). I want to avoid allocating memory for this on the heap and instead allocate using virtual memory.
The memory initially needs to be cleared to 0xFF (like NAND is). However I don't want to pay for that initialization (nor commit un-accessed pages). So ideally it should only allocate upon access. And I do not need to retain the data following exit of the simulation.
Initial ideas are
VirtualAlloc. Not sure but thinking perhaps could use guard page and then trap the exception on first access. Not sure its ideal that a DLL handles such SEH exceptions? Or is there a better way?
Create a big file that's initialized to 0xFF. Then map view of file with copy-on-write.
Anyone know if it is possible to create a file with a callback for providing the initial data?
Think probably 1) the way to go but wondering if that's really the best option.
Edit:
3) I've come up with another method that can avoid exception handler and also avoids creating a huge file:
Create a file that is same size as dwAllocationGranularity (64KiB typically). Fill with 0xFF. Then create multiple copy-on-write views of that in contiguous memory using MapViewOfFileEx + FILE_MAP_COPY (after an initial VirtualAlloc/VirtualFree to get a suitable base address that we can hope to allocate juxtapositioned views). Need to test this a bit more fully - slight concern about potential thread races.. I'm ony actually using a single thread but the CRT does start a few too.
This means that any code that only reads the virtual NAND also does not result in all pages getting committed.
yes, basically 1 is best solution. only i be do next changes - use VEH instead SEH - SEH handler will be called only if you access memory inside it, when in case VEH - access can be ai any context and thread. and instead use guard page, i be initial only reserve region of memory without real allocation. so any access to memory region lead to exception, you handle it in VEH - commit memory and fill with 0xFF pattern. demo code
PVOID g_NandBegin;
SIZE_T g_NandSize = 0x1000000;
LONG NTAPI Vex(::PEXCEPTION_POINTERS ExceptionInfo)
{
::PEXCEPTION_RECORD ExceptionRecord = ExceptionInfo->ExceptionRecord;
if (ExceptionRecord->ExceptionCode == STATUS_ACCESS_VIOLATION &&
ExceptionRecord->NumberParameters > 1)
{
PVOID pv = (PVOID)ExceptionRecord->ExceptionInformation[1];
if ((ULONG_PTR)pv - (ULONG_PTR)g_NandBegin < g_NandSize)
{
SIZE_T RegionSize = 1;
if (0 <= NtAllocateVirtualMemory(NtCurrentProcess(), &pv, 0, &RegionSize, MEM_COMMIT, PAGE_READWRITE))
{
RtlFillMemoryUlong(pv, RegionSize, MAXULONG);
return EXCEPTION_CONTINUE_EXECUTION;
}
}
}
return EXCEPTION_CONTINUE_SEARCH;
}
void dc()
{
if (PVOID pv = AddVectoredExceptionHandler(TRUE, Vex))
{
if (g_NandBegin = VirtualAlloc(0, g_NandSize, MEM_RESERVE, PAGE_READWRITE))
{
ULONG seed = ~GetTickCount();
int n = 0x100;
do
{
if (*(UCHAR*)((PBYTE)g_NandBegin + (((ULONG64)RtlRandomEx(&seed) * g_NandSize) >> 32)) != 0xFF)
{
__debugbreak();
}
} while (--n);
VirtualFree(g_NandBegin, 0, MEM_RELEASE);
}
RemoveVectoredExceptionHandler(pv);
}
}
Sorry if it was asked before, but I can't really google any.
I was trying to read files within the KEXT of OSX, using vnode_open() like the following:
struct vnode *vp = NULL;
kern_return_t kret;
vfs_context_t ctx = vfs_context_current();
kret = vnode_open(path, FREAD, 0, 0, &vp, ctx);
if (kret != KERN_SUCCESS) {
// Error log
} else {
proc_t proc = vfs_context_proc(ctx);
kauth_cred_t vp_cred = vfs_context_ucred(ctx);
char *buf = NULL;
int resid;
int len = sizeof(struct astruct);
buf = (char *)IOMalloc(len);
kret = vn_rdwr(UIO_READ, fvp, (caddr_t)buf,
len, 0, UIO_SYSSPACE, 0, vp_cred, &resid, proc);
vnode_close(fvp, FREAD, ctx);
if (kret != KERN_SUCCESS) {
// Error log
}
// Do something with the result.
}
vfs_context_rele(ctx);
Once the kext was loaded, the system panics and reboots. As long as vnode_open() is there, it panics.
Am I doing it wrong?
One thing that immediately stands out:
You shouldn't be using vfs_context_current() - use vfs_context_create(NULL). What's worse, you're subsequently calling vfs_context_rele(ctx); on the returned context. Only vfs_context_create retains, vfs_context_current() does not, so you're over-releasing the VFS context. This could certainly cause a kernel panic.
In general, when developing kexts, you can really be doing a lot more than just letting the system reboot after a kernel panic:
Panic logs are written to NVRAM, and on next boot, are saved to file. You can inspect them via Console.app, under "System Diagnostic Reports" starting with "kernel".
Panic logs contain a stack trace, which is by default unsymbolicated. You can symbolicate them after the crash, but it's a lot more convenient to set the keepsyms=1 boot argument and get the crash handler to symbolicate for you.
You can set up the debug boot argument to make crashes initiate the kernel debugger or core dumps, write the stack trace to serial/firewire console, etc.
These things are documented in part on Apple's site, but a bit of searching on the web might get you some more detailed information. In any case, they're incredibly useful for debugging problems like this.
I'm getting a crash as a result of a call to kmap and I don'nt know why. I'm hoping someone with more kernel knowledge than I can help with this. Here is the code:
pgd_t *pgd = pgd_offset(vma->vm_mm, userspace_addr);
pud_t *pud = pud_offset(pgd, userspace_addr);
pmd_t *pmd = pmd_offset(pud, userspace_addr);
pte_t *pte = pte_offset_map(pmd, userspace_addr);
if (pte_present_user(*pte)) {
void *p = NULL;
struct page *page = pte_page(*pte);
get_page(page);
p = kmap(page); /* CRASH HERE??? */
/* Read from 'p' */
kunmap(p);
put_page(page);
}
I've isolated that the call to kmap is the culprit, since without it the code runs fine. All pointers are valid as far as I can tell.
I'm unsure if pte_offset_map should be used in conjunction with kmap...
The code above is run with mm->mmap_sem and vma->vm_mm->page_table_lock locked and on a kthread within the kernel context.
I think I solved it. The main issue in my code was that I was passing the pointer returned from kmap into kunmap. I should have passed in the page pointer instead.
One other change would be to use pte_offset_kernel instead of pte_offset_map.
I am attempting to do some error checking to detect if a javascript callback function called from C++ generates any errors. This code crashes on the v8::String::Utf8Value constructor and I'm at a loss to figure out why.
v8::Locker locker;
v8::HandleScope scope;
v8::TryCatch tryCatch;
v8::Persistent<v8::Function> func = static_cast<PieMenu*> (info.Packet->Control)->m_callback_functions[info.Packet->Integer];
v8::Handle<v8::Value> v = func->Call ((func), 0, NULL);
if (tryCatch.HasCaught()) {
v8::String::Utf8Value exception_str(tryCatch.Exception());
if (exception_str.length() > 0) {
wxLogVerbose(std::string(*exception_str).c_str());
}
}
The error is "Access violation reading location 0x0000000000000027". This leads me to suspect a bad pointer in the exception object, but I'm not sure where else to look. Here is the stack trace:
v8.dll!v8::internal::Execution::ToString(v8::internal::Handle<v8::internal::Object> obj={...}, bool * exc=0x00000000027be8a0)
v8.dll!v8::Value::ToString()
v8.dll!v8::String::Utf8Value::Utf8Value(v8::Handle<v8::Value> obj={...})
I'm using Visual Studio 2008 and the latest trunk v8 code.
From the memory address, it very much looks like as if tries to read an attribute from an object which points to NULL.
I think your Call call is wrong. I remember that I had similar problems when passing NULL as the third parameter, even when you pass 0 arguments. Try this:
v8::Handle<v8::Value> argv;
func->Call ((func), 0, &argv);
I'd like to just know if there is a well-established standard way to ensure that one's process doesn't leak COM based resources (such as IMalloc'd objects)?
Take the following code as an example:
HRESULT STDMETHODCALLTYPE CShellBrowserDialog::OnStateChange(__RPC__in_opt IShellView *ppshv, ULONG uChange)
{
TRACE("ICommDlgBrowser::OnStateChange\n");
if (uChange == CDBOSC_SELCHANGE)
{
CComPtr<IDataObject> data;
if (ppshv->GetItemObject(SVGIO_SELECTION, IID_IDataObject, (void**)&data) == S_OK )
{
UINT cfFormat = RegisterClipboardFormat(CFSTR_SHELLIDLIST);
FORMATETC fmtetc = { cfFormat, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM stgmed;
if (data->GetData(&fmtetc, &stgmed) == S_OK)
{
TCHAR path[MAX_PATH];
// check if this single selection (or multiple)
CIDA * cida = (CIDA*)stgmed.hGlobal;
if (cida->cidl == 1)
{
const ITEMIDLIST * pidlDirectory = (const ITEMIDLIST *)(((LPBYTE)cida) + cida->aoffset[0]);
const ITEMIDLIST * pidlFile = (const ITEMIDLIST *)(((LPBYTE)cida) + cida->aoffset[1]);
ITEMIDLIST * pidl = Pidl_Concatenate(pidlDirectory, pidlFile);
// we now have the absolute pidl of the currently selected filesystem object
if (!SHGetPathFromIDList(pidl, path))
strcpy_s(path, _T("<this object has no path>"));
// free our absolute pidl
Pidl_Free(pidl);
}
else if (cida->cidl > 1)
strcpy_s(path, _T("{multiple selection}"));
else
strcpy_s(path, _T("-"));
// trace the current selection
TRACE(_T(" Current Selection = %s\n"), path);
// release the data
ReleaseStgMedium(&stgmed);
}
}
}
return E_NOTIMPL;
}
So in the above code, I have at least three allocations that occur in code that I call, with only one of them being properly cleaned up automatically. The first is the acquisition of IDataObject pointer, which increments that object's reference count. CComPtr<> takes care of that issue for me.
But then there is IDataObject::GetData, which allocates an HGLOBAL for me. And a utility function Pidl_Concatenate which creates a PIDL for me (code left out, but you can imagine it does the obvious thing, via IMalloc::Alloc()). I have another utility Pidl_Free which releases that memory for me, but must be manually called [which makes the code in question full of exception safety issues (its utterly unsafe as its currently written -- I hate MS's coding mechanics - just asking for memory to fail to be released properly].
I will enhance this block of code to have a PIDL class of some sort, and probably a CIDA class as well, to ensure that they're properly deallocated even in the face of exceptions. But I would still like to know if there is a good utility or idiom for writing COM applications in C++ that can ensure that all IMallocs and AddRef/Dispose are called for that application's lifetime!
Implementing the IMallocSpy interface (see CoRegisterMallocSpy Function) may help get you some of the way.
Note that this is for debugging only, and be careful. There are cautionary tales on the web...
You can not free the global handle returned by IDataObject::GetData, otherwise other programs can not paste from the clipboard after the data is cleaned up.
Any pidl you get from shell needs to be freed using IMalloc::Free or ILFree (same effect once OLE32.DLL is loaded into the process). Exceptions are pointers to the middle of item list which can not be freed independently. If you are worried about exceptions, guard your code with try/catch/finally and put the free code in the finally block.