Crash with debug context enabled

PowerVR Insider
,
1

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.

[scode lang="{language}"]First-chance exception at 0x762BC54F in myApp.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x002F171C.
Debug Error!

Program: …\myApp.exe

R6010

  • abort() has been called[/scode]

[scode lang="{language}"]> 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
[/scode]

2

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.

3

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).