0

There are 3 functions that occasionally signal the error EXC_BAD_ACCESS with code=1 and they are: glIsBuffer, glBindArray and glBufferSubData.

I can see on the call stack that the error is actually happening inside gleLookupHashObject - when the error is reported to be originating from the above mentioned functions. All of these functions are in the library GLEngine, there is no source code available only disassembly.

This app is multi-threaded, one thread does the prep work (the thread with the trouble) and the other does the rendering, but is locked with boost::unique_lock until the prep work is done. The code where this is happening in is pure C++ so I assume NSZombieObjects won't help here, at least they haven't yet.

The reason why this code is not obj-c is because this needs to run on iOS and Windows.

Btw, this problem does not happen on windows and only in Release mode in iOS.

I've placed glGetError all over this code and no GL errors are being reported.

Each thread has its own context and the thread that does the prep work uses the 'main' context which the second (rendering) thread is created sharing off of it. All buffers that can be shared are created off of the main context.

glampert
  • 4,371
  • 2
  • 23
  • 49
tamato
  • 838
  • 7
  • 15
  • 1
    Such memory errors are not easy to track, specially on a multithread app. I think your best starting point is to instrument the code with [Valgrind](http://valgrind.org/). – glampert Sep 30 '14 at 17:53
  • I face the same problem. But in my case it origins in glBindBuffer() call. – Maf Sep 04 '15 at 18:19

0 Answers0