Summary: | Color clear of FBO without color buffer crashes | ||
---|---|---|---|
Product: | Mesa | Reporter: | fangxun <xunx.fang> |
Component: | Mesa core | Assignee: | Ian Romanick <idr> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | medium | CC: | eric |
Version: | git | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
fangxun
2011-05-30 03:26:11 UTC
The test is checking for something that *used to be* an error but is *not* an error if GL_ARB_ES2_compatibility is available. The original bug report should have had a backtrace of the segfault in the description. I missed 'segfault' in the title. It looks like intelClear (intel_clear.c) calls intel_get_renderbuffer for the missing attachments. When this returns NULL, it sets the swrast_mask. Later, _swrast_Clear is called for those attachments. _swrast_Clear then tries to clear the buffers without checking for NULL pointers. Note that this is pre-existing bug that previously would have only affected OpenGL ES2 applications. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6462196 in clear_rgba_buffer (ctx=0x7ffff600e010, rb=0x0, buf=0) at swrast/s_clear.c:125 125 ASSERT(rb->PutMonoRow); Missing separate debuginfos, use: debuginfo-install expat-2.0.1-10.fc13.x86_64 glibc-2.13-1.x86_64 libgcc-4.5.1-4.fc14.x86_64 libstdc++-4.5.1-4.fc14.x86_64 (gdb) bt #0 0x00007ffff6462196 in clear_rgba_buffer (ctx=0x7ffff600e010, rb=0x0, buf=0) at swrast/s_clear.c:125 #1 0x00007ffff6462a4e in clear_color_buffers (ctx=0x7ffff600e010) at swrast/s_clear.c:175 #2 0x00007ffff6462ad3 in _swrast_Clear (ctx=0x7ffff600e010, buffers=256) at swrast/s_clear.c:215 #3 0x00007ffff629682b in intelClear (ctx=0x7ffff600e010, mask=0) at intel_clear.c:115 #4 0x00007ffff653f886 in _mesa_Clear (mask=17664) at main/clear.c:250 #5 0x00000000005dac59 in DrawFigureAndExpectError (tc=0x7ffff2f21010, fboPtr=0x218b820, attachPtr=0x7ffff2f21018) at /home/idr/devel/graphics/oglconform_31/src/OGLconform/fbo.c:5014 #6 0x00000000005e881b in DetachAttachmentNegativeTest (tc=0x7ffff2f21010) at /home/idr/devel/graphics/oglconform_31/src/OGLconform/fbo.c:10533 #7 0x00000000005ec524 in FramebufferObjectExec (params=0x7fffffffbc60) at /home/idr/devel/graphics/oglconform_31/src/OGLconform/fbo.c:12149 #8 0x0000000000da5769 in callFunctionHandleExceptionsInner ( funcWithParams=0x5ec3e8 <FramebufferObjectExec(testParameters*)>, func=0, params=0x7fffffffbc60, msg=0x7fffffffbb10 "during fbo test execution. \n\nIntel Conformance (fbo) failed.\n") at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/driverExceptionHandling.cpp:31 #9 0x0000000000da592a in callFunctionHandleExceptions (funcWithParams=0x5ec3e8 <FramebufferObjectExec(testParameters*)>, func=0, params=0x7fffffffbc60) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/driverExceptionHandling.cpp:62 #10 0x0000000000da4b4a in DriverExec (Func=0, FuncWithParams=0x5ec3e8 <FramebufferObjectExec(testParameters*)>, params=0x7fffffffbc60) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/driver.c:436 #11 0x0000000000da4c7c in DriverExecRGB (Func=0, FuncWithParams=0x5ec3e8 <FramebufferObjectExec(testParameters*)>, testRecord=0x1dbe160, testFilter=0x0) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/driver.c:480 #12 0x0000000000da5173 in Driver (testSchedule=0x1dbe160, testFilter=0x0) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/driver.c:597 #13 0x0000000000d74f9f in Exec (ptr=0x1cd63a0) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/shell.c:965 #14 0x0000000000da22fe in tkExec (Func=0xd74f45 <Exec(TK_EventRec*)>) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/ctkx.c:322 #15 0x0000000000d6dc7e in tkShellExecute (windSizeX=100, windSizeY=100, ExecFunc=0xd74f45 <Exec(TK_EventRec*)>, testSchedule=0x1dbe160) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/ctkshell.c:282 #16 0x0000000000d75101 in main (argc=12, argv=0x7fffffffe008) at /home/idr/devel/graphics/oglconform_31/src/CONFSHEL/shell.c:1031 Given that this is just the exposure of an ES2 failure on desktop GL testcase, this not a regression from the point of view of release criteria, so dropping priority. I've posted a test, fbo-missing-attachment-clear, to the piglit mailing list that reproduces this issue. Some other tests that were posted at the same time reproduce other similar issues. I removed 'bisected' from the subject because the bisected commit really only reveals a bug that already existed. I'm also reassigning this bug to Mesa core because the various FBO problems seem to be there. These issues should be fixed by the following commits in master: commit bb4758669c82f8979a56524db1c04ce662c783d8 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Tue Jun 7 12:38:39 2011 -0700 mesa: Ignore blits to/from missing buffers The EXT_framebuffer_object spec (and later specs) say: "If a buffer is specified in <mask> and does not exist in both the read and draw framebuffers, the corresponding bit is silently ignored." Check for color, depth, and stencil that the source and destination FBOs have the specified buffers. If the buffer is missing, remove the bit from the blit request mask and continue. Fixes the crash in piglit test 'fbo-missing-attachment-blit from', and fixes 'fbo-missing-attachment-blit es2 from'. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37739 Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net> NOTE: This is a candidate for the stable branches. commit 7f9c17aaa82f5a8a1d5f077eba4d5889d3c3b298 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Tue Jun 7 12:27:04 2011 -0700 mesa: Don't try to clear a NULL renderbuffer In an ES2 context (or if GL_ARB_ES2_compatibility) is supported, the framebuffer can be complete with some attachments be missing. In this case the _ColorDrawBuffers pointer will be NULL. Fixes the crash in piglit test fbo-missing-attachment-clear. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37739 Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net> NOTE: This is a candidate for the stable branches. Verified with Mesa commit 0e8d045bf8bc930576cc69b9de8a31a4c973dc7c. |
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.