Hmm, --enable-debug=full ;-) When that is in effect everything becomes real s.l.o.w due to the extra logging, but more importantly it enables all the assertions, including those around checking the lengths around the memcpy.

All platforms should be equally vulnerable. Is there any particular sequence that has a higher failure rate?

(In reply to comment #1)
> Hmm, --enable-debug=full ;-) When that is in effect everything becomes real
> s.l.o.w due to the extra logging, but more importantly it enables all the
> assertions, including those around checking the lengths around the memcpy
> All platforms should be equally vulnerable.

> Is there any particular sequence that has a higher failure rate?

Before --enable-debug=full, (I thought) the segfault only happened when there was some heavy action playing Flash applets. However, with debugging enaled, the assert failed way earlier, sometimes even before I even did anything particular at all.

Created attachment 51171 [details]
Backtrace of the assertion failure

Created attachment 51172 [details]
Xorg.log of the crashed X with --enable-debug=full

I took the last 1000 lines of the log, as the whole log is about 60M. Just let me know when you need more.

Ok, that's a different (non-critical) bug I'm trying to understand. The goal is to mirror the active lists in the kernel and so predict which buffers I can write to without stalling, that assert tells me that a buffer I thought was idle is still on the kernel active list.

diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 82c5cf1..1a1813a 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -596,7 +596,7 @@ void kgem_retire(struct kgem *kgem)
                        list_del(&bo->request);
                        bo->rq = NULL;
 
-#if 0
+#if 1
                        /* XXX we loose track of a write-flush somewhere? */
                        if (!bo->needs_flush)
                                bo->needs_flush = kgem_busy(kgem, bo->handle);

That will get you past the assertion and onto the real issue (hopefully).

It seems I only encounter the tame flash applets. I've not yet reproduced this with video elements in flashplugin either in firefox or chromium. Any suggestions as to which to try?

(In reply to comment #6)
> It seems I only encounter the tame flash applets. I've not yet reproduced this
> with video elements in flashplugin either in firefox or chromium. Any
> suggestions as to which to try?

First of all, my Flash version is 11.0 d1 on x86_64.Maybe it is related to a particular version of Flash.

Then, it can happen with nearly all videos. I have seen it happen on Youtube and golem.de. It sometimes happens the first time I want to play a video, sometimes after the like 20th time. I can not reproduce this bug reliably, only by starting the videos over and over again.

Created attachment 51201 [details]
Xorg.log with full debugging and the original segfault

"memcpy_blt: src=(0, 25), dst=(65, 409)" gives a bit of a clue - that we are skipping the first 25 lines of the PutImage data, yet still copying the full height. Hmm, are you using a compositing WM? (Which adds yet another coordinate transform I may have messed up...)

I think this is the bug... I'm never wholly convinced I have these transformations right through.

commit 3565c48c4bb77c836d817de75d098791dbb529d3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 14 17:45:41 2011 +0100

    sna: Yet another s/x/y/ typo
    
    Every time I do a transformation into pixmap space I like to include one
    of these copy'n'paste errors.
    
    Reported-by: Paul Neumann <paul104x@yahoo.de>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40850
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I cannot verify that the crashes are fixed (as I have not experienced any yet), but the patch fixed some visual corruption in Flash videos of around 25px at the bottom of the video (which I thought was an other bug >.<).

Anyways, thanks very much for your help :).

(In reply to comment #10)
> I think this is the bug... I'm never wholly convinced I have these
> transformations right through.
> 
> commit 3565c48c4bb77c836d817de75d098791dbb529d3
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Sep 14 17:45:41 2011 +0100
> 
>     sna: Yet another s/x/y/ typo
> 
>     Every time I do a transformation into pixmap space I like to include one
>     of these copy'n'paste errors.
> 
>     Reported-by: Paul Neumann <paul104x@yahoo.de>
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40850
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

That's fast. I was just trying to reproduce this bug (I first experienced it yesterday) with a flash-game, but I couldn't. This might explain why; I recompiled the driver with debug symbols from git-HEAD, and after than again without debug symbols, but still HEAD. So likely this is indeed fixed :)

Let's close this one and move on to the next bug. ;-)