Bug 37739

Summary: Color clear of FBO without color buffer crashes
Product: Mesa Reporter: fangxun <xunx.fang>
Component: Mesa coreAssignee: 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
System Environment:
--------------------------
Arch:           i386
Platform:       Huronriver
Libdrm:      (master)2.4.25-1-g61be94018ae9c403517d53f69357719224fa6ff3
Mesa:     (master)828b26b7ebe7e4c756a6cfde04646e8a112166ac
Xf86_video_intel: (master)2.15.0-17-g9d6e02a135efdea1d169d1938359ab2b553e941c
Xserver:(master)xorg-server-1.10.0-385-g0de7cec90738a7a5020150309866bb0e23b6f479
Kernel: (drm-intel-next)caee6066332b83e7f8bdd6f2f40ce46d4836d69c


Bug detailed description:
-------------------------
It fails on all platform. Bisect shows d3451f7f9c095204105259bb989428709fc1fdf0
is the first bad commit.
commit d3451f7f9c095204105259bb989428709fc1fdf0
Author:     Eric Anholt <eric@anholt.net>
AuthorDate: Wed May 25 13:51:26 2011 -0700
Commit:     Eric Anholt <eric@anholt.net>
CommitDate: Thu May 26 08:54:29 2011 -0700

    mesa: Allow NULL read/draw in complete FBOs in ARB_ES2_compatibility.

    From the ARB_ES2_compatibility spec:

        "(8) How should we handle draw buffer completeness?

        RESOLVED: Remove draw/readbuffer completeness checks, and treat
        drawbuffers referring to missing attachments as if they were NONE."

    Fixes arb_es2_compatibility-drawbuffers when the short-circuit for
    ARB_ES2_compatibility in the previous commit is dropped.


Reproduce steps:
-------------------------
1. start X
2. ./oglconform -z -s -suite all -v 2 -D 33 -test fbo negative.detachedTex
Comment 1 Ian Romanick 2011-05-31 11:51:29 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.
Comment 2 Ian Romanick 2011-05-31 12:28:27 UTC
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
Comment 3 Eric Anholt 2011-05-31 18:11:21 UTC
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.
Comment 4 Ian Romanick 2011-06-02 14:14:24 UTC
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.
Comment 5 Ian Romanick 2011-06-07 18:32:11 UTC
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.
Comment 6 fangxun 2011-06-08 22:18:52 UTC
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.