LIBGL_BATCH causing a crash (NPE)
Hello there, This crash can be reproduced with pretty much any version of gl4es since 1.1.4 as far as I'm aware.
With later versions of minecraft, using LIBGL_BATCH with any parameter (here, LIBGL_BATCH=2) results in a more or less immediate crash. 1.18.2 crashes before the first image, while 1.16.5 quickly crashes upon entering a world.
For the purpose of this report, both 1.16.5 vanilla and optifine 1.18.2 have been tested. Both tombstones are available here, and were produced from a fork of upstream with custom shader conversion.
There is no line number in the stack trace for gl4es. I need to reproduce the issue on one of dev. env. to fix this.
Never managed to get the line numbers out of stacktraces. How can I extract those out ?
An unstripped "-g" build doesn't get the line numbers?
Nope, -g, unstripped and no -O used. DEBUG is defined too.
Rebuilt on my pc from scratch, tombstone + DBG log. NDK 24.0.8215888 tombstone+log.zip
Ok, thanks to the full debug log, I think I understood why there is a crash. It's because of this sequence:
glGenBuffers(1, 0x70c1455bbc)
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0)
glBindBuffer(GL_ARRAY_BUFFER, 0)
glBindVertexArray(0)
glBindVertexArray(4)
glBindBuffer(GL_ARRAY_BUFFER, 9)
glEnableVertexAttrib(0)
glVertexAttribPointer(0, 3, GL_FLOAT, 0, 20, 0x0), vertex buffer = 0x0
glEnableVertexAttrib(2)
glVertexAttribPointer(2, 2, GL_FLOAT, 0, 20, 0xc), vertex buffer = 0x0
glBufferData(GL_ARRAY_BUFFER, 80, 0x70b36ee240, 0x88E8)
The issue is: the glVertexAttribPointer(...) are assigned before the glBufferData(...) actualy defined the memory area!
I need to make some changes (possibly heavy) to fix this issue.
EDIT: or maybe not, it might be more complex, damn
To try understand were the crash happens, can you tell me if it crashed with LIBGL_NOVAOCACHE=1 enabled?
From what I can gather, exactly the same thing, it crashed before even displaying anything other than a black screen
Same as before with 1.16.5 as well tomstone + log 1.16.5.zip
I've performed additional testing for both 1.16.5 and 1.18.2 since tombstones were different. As I kinda expected given how the tombstone was really similar to #381 , using a fork based on 1.1.4 and not 1.1.5 upstream solved the issue for 1.16.5. It did stay the same for 1.18.2.
I tried to fix the issue "blindly". So I just know I haven't broken basic stuff with this fix, and hopefully, it will fix the crash you were experiencing (if I understood the tombstone trace correctly). I might crash at a different place tho.
On a side note, I'm not sure Batch mode will help performances here, because it seems VBO are already used, and Batch mode will just break down the VBOs to create large draw command.
I'm not sure if it will improve the performance either, although having a lot of small draw commands has quite the CPU overhead.
I'll test this commit shortly, and will report the results
Hmmm, the tombstone looks different, same for the log file which seems to go further tombstone + log 1.18.2.zip