| Summary: | piglit glean/vertProg1 core dumps with RV790 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Chris Rankin <rankincj> |
| Component: | Drivers/DRI/R600 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | dima |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
This same bug seems to be triggered by "bin/vp-bad-program -auto". The problem happens when destroying the GLContext: - we call _mesa_free_context_data(), which sets ctx->DrawBuffer = NULL - _mesa_free_context_data() then calls _mesa_free_texture_data() - _mesa_free_texture_data() calls r600DeleteTexture() - r600DeleteTexture() calls radeonFlush() via radeon_firevertices() - radeonFlush() tries to dereference ctx->DrawBuffer, which has just been set to NULL - BANG! Adding a simple (ctx->DrawBuffer != NULL) check to radeonFlush() makes 43 of the vertProg1 piglit tests pass, with 2 failures: Program: RSQ test 2 (reciprocal square root of negative value) Expected color: -1, 0.1, 0.447, 1 Observed color: 0, 0, 0, 0 Program: LIT test 2 (degenerate case: 0 ^ 0 -> 1) Expected color: 1, 0.65, 1, 1 Observed color: 1, 0.65098, 0, 1 Patches are welcome :) You can send the fix to mesa3d-dev@lists.sourceforge.net. git commands format-patch and send-email are very easy tools to send patches to the mailing list. (In reply to comment #3) > Patches are welcome :) Actually, I would describe this as "the cause" rather than "the fix". I was hoping that someone who understands what the code *should* be doing would step in at this point. Maybe Mesa shouldn't be calling radeonFlush() in the first place here? Or maybe ctx->DrawBuffer shouldn't be unreferenced so early in the clean-up sequence? I have no intention of papering over this bug with an off-hand NULL check at this stage. I think this may have been fixed by fef9b532cd1631cc53056b9eba4369d1310b88df. For reference, the bug that patch fixes happens when a context is destroyed that's not the current context. For example because the current context has already been set to NULL. *** Bug 28260 has been marked as a duplicate of this bug. *** Note: classic r600 driver has been abandoned. all glean/vertProg1 tests pass with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 |
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.
The vertProg1 test core dumps because ctx->DrawBuffer is NULL in the radeonFlush() function: Core was generated by `bin/glean -r foo -t vertProg1'. Program terminated with signal 11, Segmentation fault. #0 0x00007f7f4f7ed36a in radeonFlush (ctx=0x1cd9b30) at radeon_common.c:1129 1129 if ((ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty) { Missing separate debuginfos, use: debuginfo-install expat-2.0.1-8.fc12.x86_64 glibc-2.11.1-1.x86_64 libICE-1.0.6-1.fc12.x86_64 libSM-1.1.0-7.fc12.x86_64 libX11-1.3-1.fc12.x86_64 libXau-1.0.5-1.fc12.x86_64 libXdamage-1.1.2-1.fc12.x86_64 libXext-1.1-2.fc12.x86_64 libXfixes-4.0.4-1.fc12.x86_64 libXi-1.3-2.fc12.x86_64 libXmu-1.0.5-1.fc12.x86_64 libXt-1.0.7-1.fc12.x86_64 libXxf86vm-1.1.0-1.fc12.x86_64 libdrm-2.4.18-0.1.fc12.x86_64 libgcc-4.4.3-4.fc12.x86_64 libjpeg-6b-46.fc12.x86_64 libstdc++-4.4.3-4.fc12.x86_64 libtiff-3.9.2-3.fc12.x86_64 libuuid-2.16.2-7.fc12.x86_64 libxcb-1.5-1.fc12.x86_64 zlib-1.2.3-23.fc12.x86_64 (gdb) print ctx $1 = (GLcontext *) 0x1cd9b30 (gdb) print ctx->DrawBuffer $2 = (GLframebuffer *) 0x0