I haven't given up on finding the issue here, but for now, I'm still with no lead...
I know it's something happening in the GLES driver. I get the same info (it's a memcpy inside GLES driver, nothing more) where I use GLES1 or GLES2 backend from gl4es. I don't even know if it's a drawing command or something else. Also, running with valgrind didn't gave much info (but it did show me a place on the OpenAL code where I do a memcpy and should have used a memmove).
I'll try reproducing with some other SGX driver, maybe that will show something. I also have to try on something else than the Pandora (unless it's specific code, but then, I can also remove those graphic optim and check if it reproduce).
Still some work to fix that bug...
[doublepost=1519489850,1519483887][/doublepost]Ah, using SGX driver 4.03.02 and GLES1, I got a real stacktrace using Valgrind!
==1033== Invalid read of size 4
==1033== at 0x4830DE0: memcpy (vg_replace_strmem.c:1019)
==1033== by 0x5A29AD7: CopyVArrayDataDeindex (drawvarray.c:611)
==1033== by 0x5A2A83B: DrawBatchOnVBuffer (drawvarray.c:1276)
==1033== by 0x5A2C4E7: glDrawElements (drawvarray.c:2554)
==1033== by 0x4A3131B: glDrawElements (gl.c:1129)
==1033== by 0x4A32EFF: glDrawArrays (gl.c:1234)
==1033== by 0x4A31D3B: glDrawArrays (gl.c:1172)
==1033== by 0xF018F: buff_flush() (opengl.cpp:626)
==1033== by 0xF1BB3: buff_leave (opengl.cpp:634)
==1033== by 0xF1BB3: glDrawWorld(view_t*, int) [clone .part.9] (opengl.cpp:1227)
==1033== by 0x1D467: glDrawWorld (opengl.cpp:663)
==1033== by 0x1D467: main (game.cpp:2734)
At least something a bit more precise to work on... (and yes, it's specific Pandora optimization code I wrote, to batch stuff
[doublepost=1519494411][/doublepost]Ok, found the bug (stupid mistake of course). New version updated to the repo.
- Fix a bug that could make the game to crash