Tracking down heap corruption - strange driver callstack


I’m currently researching a supposed heap corruption in a large multithreaded application. One of the suspicious threads is our render thread with the following callstack at the time of the crash (Note: Everything above the driver has been removed):

#0 SetupStreamPointers (gc=0x0, ui32First=0x0, pui32Count=0x0, bAreIndicesZeroBased=IMG_FALSE) at opengles3/drawvarray.c:320
#1 0x0000007fafa190dc in CopyVArrayData (gc=0x7ef961a700, ui32First=0x0, ui32VertexCount=0x1, ui32InstanceOffset=0x0, ui32InstanceCount=0x1, bAreIndicesZeroBased=IMG_FALSE) at opengles3/drawvarray.c:486
#2 0x0000007fafa1a468 in DrawElementsIndexBO (gc=0x7ef961a700, eMode=0x4, pui32First=0x7fa805d734, pui32Count=0x7fa805d650, ui32NumIndices=0x6d8, ui32IndexType=0x1, elements=0x7fa805d678, ui32VertexStart=0x0,
ui32VertexCount=0x1, ui32PrimCount=0x1, ui32InstanceCount=0x1, pi32BaseVertex=0x7fa805d634) at opengles3/drawvarray.c:1257
#3 0x0000007fafa200a4 in DrawElements (gc=0x7ef961a700, mode=0x4, psIndexRange=0x0, count=0x6d8, type=0x1403, indices=0x0, instancecount=0x1, basevertex=0x0, pszFuncName=0x7fafbbe4b0 “glDrawElements”)
at opengles3/drawvarray.c:5050
#4 0x0000007fafa20228 in glDrawElements (mode=0x4, count=0x6d8, type=0x1403, indices=0x0) at opengles3/drawvarray.c:5101

What looks especially suspicious for me is gc=0x0 in the bottom frame. Do these values look valid?

It is an embedded powervr target with a linux a 1.9 driver.



what PowerVR GPU does your system have?
Can you tell me the exact driver version from GL_VERSION string? 1.9@xxx?


OpenGL ES 3.1 build 1.9@4908383
PowerVR Rogue GX6250


Thank you, is there a chance we can get the app? We can look at it using a debug driver.
Otherwise I can just raise a bug with the info and hope that it will be enough :slight_smile:


Unfortunately not since it is proprietary. My first guess is that there is something within the SetupStreamPointers method that overwrites parts of the stack with zeroes.

Allright, no problem. I’ll forward this to the driver team, hopefully they can fix it.


another idea I had was that I’ll ask around if we can supply you with a newer driver to see if the problem is already solved in newer code. (can’t guarantee I can get you a newer driver though).

Thanks for reporting the issue.



couple of other things that might help us resolve your issue:

  1. Can you send us a PVRTrace recording of your application?
  2. Can you maybe create a unit-test so we can replicate your problem?
  3. We can also talk about this under NDA, you can re-submit your issue here for private support:



unfortunately, the error could not be reproduced at the moment so making a trace is not possible.