That hints to memory corruption. Are you using textured or the overlay adaptor? [And what is calling XGetImage? ;-]

In the vlc settings, i have enabled the "Accelerated video output (Overlay)" checkbox and "XVideo output (XCB)". Is this measurement reliable enough?

Despite what it says, it uses the TexturedAdaptor as opposed to the OverlayAdaptor. Not that it makes much difference, and is certainly preferable with a compositing manager. Which brings us to the next point. Running X under valgrind whilst using xfce4 and vlc, the only hits I'm getting are use of uninitialised values within XComposite. (They would appear to have been fixed in xserver.git, but not yet in my distro X package.)

Please can you keep running X under gdb (or grabbing the core file) and attach any other stacktraces if they differ.

What version of X are you using? I keep hitting lots of bugs in 1.11.2.901 (including memory corruption) that I know are fixed in 1.11.99.1...

I am using 1.11.2.
I just happened to experience another crash. This time with mplayer however and the backtrace looks different.

Created attachment 54324 [details]
Backtrace of X crashing with mplayer

Yup, that does suggest memory corruption. If you feel brave (and can withstand a slow desktop for a bit), you can try ./configure --enable-sna --enable-debug=full which will check everything I've had the foresight (or bad experience) to assert.

Created attachment 54428 [details]
tail -n 10000 of Xorg.log of the crash

I managed to crash X by using Xv and having gtkperf open at the same time very quickly. I am not sure whether this is the bug I am looking for, as the backtrace seems completely different, but I just want to let you know.

Created attachment 54429 [details]
backtrace of the crash I have Xorg.log of

Unfortunately that's a separate bug:

commit 95cceb5ae5503af0ac50a923fa47e134f0da8743
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 14 19:27:53 2011 +0000

    sna: Fix DBG crash whilst pruning inactive GPU buffers
    
    Don't attempt to dereference the NULL gpu_bo after having just freed it.
    Here in lies the folly of trying to blindly silence the compiler.
    
    Instead we should heed the error return as it means that we didn't
    decouple the pixmap from the inactive list and so we choose to place it
    back on the active list to purge again in the near future.
    
    Reported-by: Paul Neumann <paul104x@yahoo.de
    References: https://bugs.freedesktop.org/show_bug.cgi?id=43716
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I've almost got my 945gm ready to roll again...

I'm running gtkperf and mplayer in a loop, with and without compiz. Do I need anything else to trigger this? Seems happy enough with that so far...

(In reply to comment #11)
> I'm running gtkperf and mplayer in a loop, with and without compiz. Do I need
> anything else to trigger this? Seems happy enough with that so far...

Gtkperf shouldn't really be necessary, this only triggered the bug you already fixed. I am using xfwm4 with compositing enabled.
What I also noticed is that I can relatively easily reproduce this without --enable-debug=full (seldom more than 30 minutes of watching video), but with full debugging, X never crashed in such a short time which is kind of problematic since I "only" have about 17G on / for the logs ;).

Ok, I used xfce4-session instead of compiz, and ran X under valgrind, not even a whimper. :(

Can you keep on pasting the crash backlogs, and see if you can narrow down the reproduction steps?

Created attachment 54469 [details]
yet another backtrace of X

So what I did this time (xfwm4 with composting, DDX -git from just half an hour ago):

- turn on vlc, windowed
- browse around a bit with chromium (no flash because of chromium' click-to-play)
- quit chromium
- watch vlc in fullscreen (the same stream as before, MPEG2 DVB-T)
- segfault happens

total time maybe 20-30 minutes

If you want I can leave the chromium part away or even start vlc in twm.

Looks to be another unrelated buglet, keep them coming! :>

I think this is only possible after/during a gpu hang, but anyway crashing is not an option...

commit 19c184b7e4f8de747ed6fb1f6f910238193cf2a1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Dec 15 18:18:19 2011 +0000

    sna/gen3: Check for upload failure of video bo
    
    And propagate that failure back to the client.
    
    Reported-by: Paul Neumann <paul104x@yahoo.de>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=43716
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Is it the same movie every time? Video format, source size, output placement all can cause the code to behave slightly differently. I'm guessing from the source size that you're playing back an mpeg2ts stream, or perhaps dvd?

(In reply to comment #16)
> Is it the same movie every time? Video format, source size, output placement
> all can cause the code to behave slightly differently. I'm guessing from the
> source size that you're playing back an mpeg2ts stream, or perhaps dvd?

It is TV but it is mostly the same channel.
Here is the ffmpeg -i output:

Stream #0:1[0x101]: Video: mpeg2video (Main), yuv420p, 704x576 [SAR 16:11 DAR 16:9], 10000 kb/s, 25.20 fps, 25 tbr, 90k tbn, 50 tbc

Hmm, the crashes seem to be gone. However, after some time now, the video is not updated anymore until I manually resize the window.
The only pattern I have seen now, although I have not investigated very much yet, is: watching video in fullscreen -> after some time it stops -> exiting fullscreen makes the video update again.
I hope this could give you any idea about what is going on.

When the video stops, could you make a note of system activity (top, sudo perf top) and if anything unusual appears in the logs. Otherwise there is no real difference between the first frame and the 1,000,000th except for the accumulation of errors...

Although the first crashes were before the introduction of some of the recent bugs, can you try updating to get the crash fix for the vma cache, and cross your fingers! ;-)

(In reply to comment #20)
> Although the first crashes were before the introduction of some of the recent
> bugs, can you try updating to get the crash fix for the vma cache, and cross
> your fingers! ;-)

I crossed my fingers, but it didn't help :(. As before, there are no crashes anymore but after some time, the video stalls. This only happens when vlc is in fullscreen.

However, as you suggested earlier, I tried 1.11.99.2 and it works so far, no crashes, no video stalls. It works perfectly.

As I am not able to reproduce the bug when enabling full debugging and the issue is fixed in 1.12, I don't know whether there is a point in trying to provide meaningful logs so you can think of a workaround.
Besides, I have no access to my 945gm in the next three weeks.

Anyways, thank you very much for your help :).

Hmm, that perhaps points towards one of the Composite bugs fixed in the xserver. But I still don't have a clue, so lets leave this open for the time being and do enjoy the holidays!

Now this could explain why you had a failure that took a long time to show up...

commit fed8d145c148bfa8a8a29f4088902377f9a10440
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Dec 18 19:26:38 2011 +0000

    sna: Use a safe iterator whilst searching for inactive linear bo
    
    As we may free a purged bo whilst iterating, we need to keep the next bo
    as a local member.
    
    Include the debugging that led to this find.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I'm considering this bug closed for now, let me now if I break anything else when you get the chance.