<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - X-Plane 10 crashes with SIGSEGV on radeonsi" href="https://bugs.freedesktop.org/show_bug.cgi?id=97909#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - X-Plane 10 crashes with SIGSEGV on radeonsi" href="https://bugs.freedesktop.org/show_bug.cgi?id=97909">bug 97909</a> from <a class="email" href="mailto:nhaehnle@gmail.com" title="Nicolai Hähnle <nhaehnle@gmail.com>"> Nicolai Hähnle</a> <pre>Okay, so I could reproduce this after all with the web demo. There is a bug in X-Plane and also questionable behaviour of the driver. The bug in X-Plane is that it uses GL_AMD_pinned_memory with a size that is not a multiple of a page; as per the spec, the driver is allowed to reject that, and we do (apparently unlike the closed source driver...). X-Plane doesn't check this error condition, and continues rendering, hence the crash, which would also happen with a simple sequence of: glGenBuffers(1, &bo); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, bo); glDrawElements(...); Somewhat surprisingly, the OpenGL spec never states that a draw call that goes outside the element/index buffer should flag a GL_INVALID_OPERATION. There is also no mention of this in the GL_ARB_robust_buffer_access_behavior extension, which is surprising. The patch you provide may or may not go in the right direction - I'm not sure. If we want to check that, we should do it in api_validate.c, but I'm not convinced that we should. Meanwhile, that check wouldn't properly fix the issue in X-Plane. To work around the bug in X-Plane, you need to run with: MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory ./X-Plane-x86_64 --force_run which will work with an unmodified driver.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>