Bug 41211

Could you please get a full backtrace, with debug symbols installed, etc., and with gdb instead of just from the log?

http://x.debian.net/howto/use-gdb.html could be a start.

(In reply to comment #1)
> Could you please get a full backtrace, with debug symbols installed, etc., and
> with gdb instead of just from the log?
> 
> http://x.debian.net/howto/use-gdb.html could be a start.

there's an attachment 'backtrace' containing exactly that...

My suspicion is that you've hit this bug:

http://cgit.freedesktop.org/~ickle/xserver/commit/?id=65a272e7ae9392a5716a620d669ef5261241bc4b

At least the trace looks very similar. Does valgrind give a hint as to who freed the list?

In which case, and assuming this is a standalone commit, Wouter could try something like that:

sudo apt-get build-dep xorg-server
git clone git://people.freedesktop.org/~kibi/xserver -b fdo41211
cd xserver
DEB_BUILD_OPTIONS="noudeb parallel=42" debuild -b
sudo debi --upgrade

Hi,

Sorry for the late followup; originally I didn't have the time to do some more debugging, and then I plain forgot.

I tried recompiling my X server using the procedure suggested by Cyril, but that didn't fix the issue.

I've run the following:

valgrind --leak-check=full --leak-resolution=high --track-origins=yes --trace-children=yes X :1

inside a script(1) session, and will attach the output of that to this bugreport momentarily.

Created attachment 52625 [details]
valgrind output

==25228== Invalid read of size 4
==25228==    at 0x8B6EA4E: DRI2WaitSwap (dri2.c:783)
==25228==    by 0x832DC97: __glXDRIcontextWait (glxdri2.c:290)
==25228==    by 0x832406B: __glXForceCurrent (glxext.c:411)
==25228==    by 0x83278A5: DoGetString (single2.c:326)
==25228==    by 0x8323D68: __glXDispatch (glxext.c:547)
==25228==    by 0x437AE8: Dispatch (dispatch.c:432)
==25228==    by 0x426EA9: main (main.c:287)
==25228==  Address 0x34 is not stack'd, malloc'd or (recently) free'd
==25228== 
==25228== 
==25228== Process terminating with default action of signal 11 (SIGSEGV)
==25228==  General Protection Fault
==25228==    at 0x688B2C6: sprintf (sprintf.c:29)
==25228==    by 0x57364A: LogVWrite (log.c:275)
==25228==    by 0x57338B: ErrorF (log.c:572)
==25228==    by 0x568968: xorg_backtrace (backtrace.c:44)
==25228==    by 0x56C558: OsSigHandler (osinit.c:129)
==25228==    by 0x56D601F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.13.so)
==25228==    by 0x8B6EA4D: DRI2WaitSwap (dri2.c:791)
==25228==    by 0x832DC97: __glXDRIcontextWait (glxdri2.c:290)
==25228==    by 0x832406B: __glXForceCurrent (glxext.c:411)
==25228==    by 0x83278A5: DoGetString (single2.c:326)
==25228==    by 0x8323D68: __glXDispatch (glxext.c:547)
==25228==    by 0x437AE8: Dispatch (dispatch.c:432)
==25228==

Random patch:

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 1d1e06f..f42d0a8 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -823,7 +823,8 @@ DRI2WaitSwap(ClientPtr client, DrawablePtr pDrawable)
     /* If we're currently waiting for a swap on this drawable, reset
      * the request and suspend the client.  We only support one
      * blocked client per drawable. */
-    if ((pPriv->swapsPending) &&
+    if (pPriv &&
+       pPriv->swapsPending &&
        pPriv->blockedClient == NULL) {
        ResetCurrentRequest(client);
        client->sequence--;

(In reply to comment #8)
> Random patch:
> 
> diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
> index 1d1e06f..f42d0a8 100644
> --- a/hw/xfree86/dri2/dri2.c
> +++ b/hw/xfree86/dri2/dri2.c
> @@ -823,7 +823,8 @@ DRI2WaitSwap(ClientPtr client, DrawablePtr pDrawable)
>      /* If we're currently waiting for a swap on this drawable, reset
>       * the request and suspend the client.  We only support one
>       * blocked client per drawable. */
> -    if ((pPriv->swapsPending) &&
> +    if (pPriv &&
> +       pPriv->swapsPending &&
>         pPriv->blockedClient == NULL) {
>         ResetCurrentRequest(client);
>         client->sequence--;

That seems to do the trick, yes. Thanks!

Ok, so let's get that sanity check merged ... but we should also figure out why 
pPriv was NULL...

(In reply to comment #10)
> Ok, so let's get that sanity check merged ... but we should also figure out why 
> pPriv was NULL...

Fair enough. Is there any test you want me to run?

Chris, please send this to xorg-devel to get a review.  What is holding this up?

I pulled this into my tree and sent a [PULL] request to xorg-devel.

commit 73beaf9033d9a44e7a7c654f296624c7265eeb6d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 24 11:17:03 2011 +0000

    DRI2: Avoid a NULL pointer dereference
    
    Bugzilla:  https://bugs.freedesktop.org/show_bug.cgi?id=41211
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
    (cherry picked from commit bfa1a0dd190ed88020d60eba3bb04681c8e83a68)

What was committed was just a workaround.  Reopening and removing from the 1.11 tracker.

*** Bug 42279 has been marked as a duplicate of this bug. ***

*** Bug 43163 has been marked as a duplicate of this bug. ***

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.