0

This bug seems to only happen in iOS Simulator, but it happens often enough that it is affecting my work.

Randomly, the app will crash in glDrawElements.

Normally, there is no ouput, but when running with GuardMalloc, I got this:

GuardMalloc[Sketch Nation Galaxy-92006]: Failed to VM allocate 16777216 bytes GuardMalloc[Sketch Nation Galaxy-92006]: Explicitly trapping into debugger!!! dlopen(/Applications/Xcode.app/Contents/PlugIns/DebuggerFoundation.ideplugin/Contents/Resources/DebuggerIntrospectionSupport.dylib, 0x00000002) dyld: loaded: /Applications/Xcode.app/Contents/PlugIns/DebuggerFoundation.ideplugin/Contents/Resources/DebuggerIntrospectionSupport.dylib

Looking at the glDrawElements call, if the crash happens when GuardMalloc IS NOT ON, everything looks normal and it does not seem like any of the vertex or index data got corrupted. Just a weird exec_bad_access inside the glDrawElements call.

When I try to look at the data when the crash happens with GuardMalloc on, there is no data for anything, regardless of how high I climb the stack trace.

I don't know if it helps, but here is the assembly inside the glDrawElements calls:

OpenGLES`glDrawElements: 0x1b3f11d: pushl %ebp 0x1b3f11e: movl %esp, %ebp 0x1b3f120: pushl %ebx 0x1b3f121: pushl %edi 0x1b3f122: pushl %esi 0x1b3f123: subl $28, %esp 0x1b3f126: movl $30, (%esp) 0x1b3f12d: calll 0x1b455c2 ; symbol stub for: pthread_getspecific 0x1b3f132: testl %eax, %eax 0x1b3f134: je 0x1b3f15e ; glDrawElements + 65 0x1b3f136: movl 20(%ebp), %ecx 0x1b3f139: movl 16(%ebp), %edx 0x1b3f13c: movl 12(%ebp), %esi 0x1b3f13f: movl 8(%ebp), %edi 0x1b3f142: movl 16(%eax), %ebx 0x1b3f145: movl %ecx, 16(%esp) 0x1b3f149: movl %edx, 12(%esp) 0x1b3f14d: movl %esi, 8(%esp) 0x1b3f151: movl %edi, 4(%esp) 0x1b3f155: movl %ebx, (%esp) 0x1b3f158: calll *288(%eax) 0x1b3f15e: addl $28, %esp <-- CRASH HAPPENS HERE 0x1b3f161: popl %esi 0x1b3f162: popl %edi 0x1b3f163: popl %ebx 0x1b3f164: popl %ebp 0x1b3f165: ret

Anyone have any idea?

This crash happens randomly on any of my glDrawElement calls. My most common call is to a "triangle-strip square" used to render sprites:

glVertexPointer( 3, GL_FLOAT, byteStride, m_pVertexData ); glTexCoordPointer( 2, GL_FLOAT, byteStride, m_pVertexData+6 ); glDrawElements(GL_TRIANGLE_STRIP, m_numVertices, GL_UNSIGNED_BYTE, m_pIndices);

m_pVertexData is created from m_pVertices, which is a struct.

m_numVertices = 4; m_stride = sizeof( GEMeshVertex ) / sizeof( GLFloat ); int vertexCounter = 0; m_pVertices[vertexCounter].x = -0.5; m_pVertices[vertexCounter].y = 0.5; m_pVertices[vertexCounter].z = 0; m_pVertices[vertexCounter].nx = 0; m_pVertices[vertexCounter].ny = 0; m_pVertices[vertexCounter].nz = 1; m_pVertices[vertexCounter].tu = 0; m_pVertices[vertexCounter].tv = 1; vertexCounter++; m_pVertices[vertexCounter].x = -0.5; m_pVertices[vertexCounter].y = -0.5; m_pVertices[vertexCounter].z = 0; m_pVertices[vertexCounter].nx = 0; m_pVertices[vertexCounter].ny = 0; m_pVertices[vertexCounter].nz = 1; m_pVertices[vertexCounter].tu = 0; m_pVertices[vertexCounter].tv = 0; vertexCounter++; m_pVertices[vertexCounter].x = 0.5; m_pVertices[vertexCounter].y = 0.5; m_pVertices[vertexCounter].z = 0; m_pVertices[vertexCounter].nx = 0; m_pVertices[vertexCounter].ny = 0; m_pVertices[vertexCounter].nz = 1; m_pVertices[vertexCounter].tu = 1; m_pVertices[vertexCounter].tv = 1; vertexCounter++; m_pVertices[vertexCounter].x = 0.5; m_pVertices[vertexCounter].y = -0.5; m_pVertices[vertexCounter].z = 0; m_pVertices[vertexCounter].nx = 0; m_pVertices[vertexCounter].ny = 0; m_pVertices[vertexCounter].nz = 1; m_pVertices[vertexCounter].tu = 1; m_pVertices[vertexCounter].tv = 0; m_pIndices = new GLubyte[m_numVertices]; m_pIndices[0] = 0; m_pIndices[1] = 1; m_pIndices[2] = 2; m_pIndices[3] = 3; for( i = 0; i < m_numVertices; i++ ) { m_pVertexData[(i*stride)+0] = m_pVertices[i].x; m_pVertexData[(i*stride)+1] = m_pVertices[i].y; m_pVertexData[(i*stride)+2] = m_pVertices[i].z; m_pVertexData[(i*stride)+3] = m_pVertices[i].nx; m_pVertexData[(i*stride)+4] = m_pVertices[i].ny; m_pVertexData[(i*stride)+5] = m_pVertices[i].nz; m_pVertexData[(i*stride)+6] = m_pVertices[i].tu; m_pVertexData[(i*stride)+7] = m_pVertices[i].tv; }

Being a 2d app, I am not using the normals.

Here is the struct that holds the m_pVertices data:

class GEMeshVertex { public: float x, y, z; // The untransformed position for the vertex. float nx,ny,nz; float tu, tv; // The texture coordinates } PACK_STRUCT;

PACK_STRUCT is a macro to byte align the struct:

# define PACK_STRUCT __attribute__((packed))
Improve this question
6
  • 1
    You're probably using the wrong array size somewhere and drawElements is trying to access an address outside of it's buffer. Can you put up the code leading up to drawElements? Anything related to buffers, pointers, etc would be relevant. Commented Oct 11, 2012 at 19:53
  • Added. Hope that helps. As you can see my vertex/indices are very simple. The same calls runs perfectly fine until the crash. If GUARD_MALLOC is not on, I can see that m_pVertexData and m_pIndices have not changed. Commented Oct 11, 2012 at 20:38
  • 1
    Is stride the same as m_stride? What size is that giving you? Commented Oct 11, 2012 at 20:43
  • When I coped and pasted the code I missed the stride = m_stride line. Stride is 8. I'll add the struct for m_pVertices to the question. Commented Oct 11, 2012 at 21:27
  • did you ever get an answer for this? having something similar... Commented Jun 3, 2013 at 14:37

1 Answer 1

Reset to default
2

I also have this problem and was unable to solve it for a long time. Only recently I discovered that it's probably not even a bug in my code. It seems that the exception is caught and handled by the simulator just fine. If I let the debugger resume execution, the application continues as if nothing happend.

The fact that my app never crashes while idling in the simulator without an attached debugger also speaks for this theory. Furthermore my app never has this problem while running on an actual device.

God knows what the OpenGL ES emulator does behind the scenes. It seems to expect this specific exception as it is prepared to recover from it.

It's a pity though that one cannot instruct Xcode to ignore specific exceptions or exceptions in specific modules. But this is rather an annoyance than a major problem.

For now I assume that everything is fine until I discover evidence that contradicts my findings.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.