When running sauerbraten with some maps (e.g.: douze map or campaign -> Private Stan Sauer -> Part II after going up the stairs, and advancing through the ogre) and shaders enabled, sometimes walls disappear and I get the following warnings: Mesa warning: glDraw[Range]Elements(start 1204, end 1331, count 297, type 0x1403, indices=0x118e) end is out of bounds (max=90) Element Buffer 11 (size 62088) This should probably be fixed in the application. Mesa warning: glDraw[Range]Elements(start 1204, end 1331, count 297, type 0x1403, indices=0x118e) index=1331 is out of bounds (max=90) Element Buffer 11 (size 62088) Skipping the glDrawRangeElements() call ... This bug was reported on sauerbraten forum at: http://cubeengine.com/forum.php4?action=display_thread&thread_id=2242 but one developer think that this could be a mesa bug. Tested with r300 and r300g.
Created attachment 39221 [details] backtrace Backtrace with mesa and sauerbraten debug symbols is attached.
This error is reported when one of the indexes/elements specified by the glDraw[Range]Elements call points to a vertex attribute that's outside the bounds of the containing VBO. If nothing is done about this, it's possible for this to cause a segfault/crash. To learn more, set a breakpoint on _mesa_warning(). When it gets hit do this in gdb: (gdb) call _mesa_print_arrays(ctx) That will print information about all the enabled vertex arrays. Please post that info.
Created attachment 39234 [details] output of call _mesa_print_arrays(ctx)
I checked all client *_ARRAY states via glIsEnabled() at the point he alleges this error occurred, and on my end, they are always disabled. (Using NV proprietary drivers) The texture coordinate array he shows as being enabled in his debug output therefor should not actually be enabled at all, unless he is somehow triggering an odd path in the code that is never reproducing for me, or somehow the bug is in the Mesa drivers themselves not disabling this array. Given my inability to reproduce this issue (again, all queried array states via glIsEnabled() are false except for the vertex array), I can not offer any help in this matter as of yet or point to anything in Sauerbraten's code that could actually be fixed.
(In reply to comment #4) > I checked all client *_ARRAY states via glIsEnabled() at the point he alleges > this error occurred, and on my end, they are always disabled. (Using NV > proprietary drivers) > > The texture coordinate array he shows as being enabled in his debug output > therefor should not actually be enabled at all, unless he is somehow triggering > an odd path in the code that is never reproducing for me, or somehow the bug is > in the Mesa drivers themselves not disabling this array. Given my inability to > reproduce this issue (again, all queried array states via glIsEnabled() are > false except for the vertex array), I can not offer any help in this matter as > of yet or point to anything in Sauerbraten's code that could actually be fixed. Okay, found a potential culprit in my code buried away in a place I still can't force it to trigger the issue, but I will have the user check and see if it fixes it for him.
Yeah, I can confirm the issue is no longer reproducible with the updated sauerbraten.
*** Bug 25706 has been marked as a duplicate of this bug. ***
*** Bug 27755 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.