Crash with debug context enabled

This topic contains 2 replies, has 2 voices, and was last updated by  Dark_Photon 1 year, 5 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #53685

    In PowerVR SDK R1.1’s PVRVFrame (win32) with KHR_debug support advertised, if an EGL debug context is enabled, CPU memory just climbs, and eventually the app crashes in VFrame’s libEGL.dll with a std::bad_alloc error. We’re seeing this on systems with ATI GPUs and NVidia GPUs.

    Note that this is without PVRTrace recorder libs plugged in. Also note that the KHR_debug APIs we use are glDebugMessageInsert (extensively), glObjectLabel (minimal), and glDebugMessageCallback.

    First-chance exception at 0x762BC54F in myApp.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x002F171C.
    Debug Error!
    Program: …\myApp.exe
    – abort() has been called
    >	msvcr110d.dll!_NMSG_WRITE(int rterrnum) Line 226	C
     	msvcr110d.dll!abort() Line 62	C
     	msvcr110d.dll!terminate() Line 97	C++
     	msvcr110d.dll!__FrameUnwindFilter(_EXCEPTION_POINTERS * pExPtrs) Line 980	C++
     	msvcr110d.dll!__FrameUnwindToState(EHRegistrationNode * pRN, void * pDC, const _s_FuncInfo * pFuncInfo, int targetState) Line 1068	C++
     	msvcr110d.dll!@_EH4_CallFilterFunc@8() Line 394	Unknown
     	ntdll.dll!777134c9()	Unknown
     	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
     	[External Code]	
     	libEGL.dll!0038254b()	Unknown
     	[External Code]	
     	libEGL.dll!0038254b()	Unknown
     	libEGL.dll!0036197e()	Unknown
     	libEGL.dll!00361156()	Unknown
     	libEGL.dll!0035d4e0()	Unknown
     	libEGL.dll!0035d454()	Unknown


    Hi Dark_Photon,

    I think I’ve found the cause of the memory growth. When debug messages are inserted the emulator is pushing them onto an internal queue to be presented in the GUI, but if the GUI isn’t running the queue just fills up with messages which are never processed. So a somewhat awkward workaround would be to leave PVRVFrameGUI running so that it empties out the message queue. I will get this bug fixed for the next release.


    Ok, thanks Chris. That’s an easy work-around, or just disable the debug context except when capturing a trace.

    The only added benefit I’m aware of for running with a debug context w/o trace capture active is that you can get callbacks for GL errors rather than have to trap them manually (e.g. add glGetError after every GL call).

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.