[Bug 91379] [intel] Unrelated glXSwapBuffers() in other thread causes glReadPixels() to fail

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Jul 17 17:10:56 PDT 2015


            Bug ID: 91379
           Summary: [intel] Unrelated glXSwapBuffers() in other thread
                    causes glReadPixels() to fail
           Product: Mesa
           Version: 10.5
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: idr at freedesktop.org
          Reporter: sgunderson at bigfoot.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org


I'm trying to get CasparCG (a broadcast graphics system) to work on my Haswell
laptop. It is unstable, frequently crashing after a minute or so. I filed a
CasparCG bug about it (https://github.com/CasparCG/Server/issues/364), but I am
increasingly leaning towards a driver bug.

CasparCG keeps multiple contexts. They are unrelated in that they never
communicate (according to upstream) but they share lists (seemingly an artifact
of SFML, the windowing system in use).

Essentially, the error is that glReadPixels() (taking the fast path, from a 2D
texture to a PBO) fails with GL_INVALID_OPERATION. Empirically, this only
happens in the case where another thread is busy doing glXSwapbuffers() (on a
different context). I don't understand the full code here, but it seems that
glReadPixels() internally needs to resolve a clear in the texture, and
internally it needs a renderbuffer to do that, and this renderbuffer somehow
ends up becoming the dummy renderbuffer and everything fails. (The _mesa_error
being called is the one in fbobject.c:2750, namely
“glFramebufferRenderbuffer(renderbuffer %u)”.) It does also seems suspect that
the resolve is emitting stuff to the batch buffer while the other thread is
busy resetting the batch buffer, although the internals here are beyond me (I
don't know if these are the same buffer, for instance).

The backtraces of the two relevant threads, with a breakpoint on
Thread 4 (Thread 0x7fffc8c9e700 (LWP 29321)):
#0  _mesa_FramebufferRenderbuffer (target=target at entry=36009,
attachment=attachment at entry=36064,
renderbufferTarget=renderbufferTarget at entry=36161, 
    renderbuffer=14247) at ../../../../src/mesa/main/fbobject.c:2750
#1  0x00007fffc8079d0b in brw_meta_resolve_color (brw=0x114c51d7a028,
mt=0x114c4eec3b00) at
#2  0x00007fffc80cec35 in intel_miptree_resolve_color
(brw=brw at entry=0x114c51d7a028, mt=<optimized out>)
    at ../../../../../../../src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1613
#3  0x00007fffc80131fc in intel_update_state (ctx=0x114c51d7a028,
new_state=<optimized out>) at
#4  0x00007fffc7e247dd in _mesa_update_state_locked
(ctx=ctx at entry=0x114c51d7a028) at ../../../../src/mesa/main/state.c:453
#5  0x00007fffc7e24ea1 in _mesa_update_state (ctx=ctx at entry=0x114c51d7a028) at
#6  0x00007fffc7e1bdc0 in _mesa_ReadnPixelsARB (x=0, y=0, width=1280,
height=720, format=32993, type=33639, bufSize=2147483647, pixels=0x0)
    at ../../../../src/mesa/main/readpix.c:979
#7  0x00007fffc7e1c122 in _mesa_ReadPixels (x=<optimized out>, y=<optimized
out>, width=<optimized out>, height=<optimized out>, format=<optimized out>, 
    type=<optimized out>, pixels=0x0) at
#8  0x0000000001dafd60 in
[…more casparcg code…]

Thread 5 (Thread 0x7fffbefb7700 (LWP 29334)):
#0  0x00007fffe8736237 in madvise () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffeb582d4c in TCMalloc_SystemRelease(void*, unsigned long) () from
#2  0x00007fffeb57bf08 in tcmalloc::PageHeap::DecommitSpan(tcmalloc::Span*) ()
from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#3  0x00007fffeb57c121 in
tcmalloc::PageHeap::MergeIntoFreeList(tcmalloc::Span*) () from
#4  0x00007fffeb57c6cb in tcmalloc::PageHeap::Delete(tcmalloc::Span*) () from
#5  0x00007fffeb586963 in (anonymous namespace)::do_free_with_callback(void*,
void (*)(void*)) [clone .constprop.42] ()
   from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#6  0x00007fffc7aea7ce in ?? () from
#7  0x00007fffc7aeaa1b in ?? () from
#8  0x00007fffc80c7425 in intel_batchbuffer_reset
(brw=brw at entry=0x114c55e3a028) at
#9  0x00007fffc80c7636 in brw_new_batch (brw=0x114c55e3a028) at
#10 _intel_batchbuffer_flush (brw=brw at entry=0x114c55e3a028,
file=file at entry=0x7fffc81c8ab0
    line=line at entry=182) at
#11 0x00007fffc80c7adf in _intel_batchbuffer_flush
(brw=brw at entry=0x114c55e3a028, 
    file=file at entry=0x7fffc81c8ab0
line=line at entry=182)
    at ../../../../../../../src/mesa/drivers/dri/i965/intel_batchbuffer.c:296
#12 0x00007fffc80d5202 in intel_dri2_flush_with_flags (cPriv=<optimized out>,
dPriv=0x114c55a2b200, flags=<optimized out>, reason=<optimized out>)
    at ../../../../../../../src/mesa/drivers/dri/i965/intel_screen.c:182
#13 0x00007fffea1d2d02 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 [I
believe this is glXSwapBuffers]
#14 0x000000000240a8e8 in sf::Window::display() ()
[…more casparcg code…]

Mesa 10.5.9, Debian unstable (sid).

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150718/70bfa083/attachment.html>

More information about the intel-3d-bugs mailing list