X.org crash when watching video with Xv on Intel graphics card

Created an attachment (id=12365)
bt full of crash, created based on core dump (still available if needed)

Created an attachment (id=12389)
xv crash #2

This is another crash related to XV. I'm adding it here since it is in some relation with closing XV "sessions".

My hardware is described here;
http://lists.freedesktop.org/archives/xorg/2007-October/029604.html

Created an attachment (id=12390)
xv crash #3

Both #2 and #3 happened when I used gmplayer and opened a second session to play a second video after the first finished (but the application still open). Maybe the mplayer code does not properly handle cases where XV is already used (the error message claimed that in both cases).

Just to note: The core dumps of all crashes are still available.

Way to reproduce:
execute
mplayer -vo xv some_video.avi
in window 1
mplayer -vo xv another_video.avi
in window 2

You can take the same avis, of course. Note that the backtraces differ, but the reason seems to be the same.

Created an attachment (id=12551)
xv crash #4

This with the two mplayer sessions approach of last comment, but I haven't tested twice, so the next attempt might cause a different backtrace.

Upping the severity since this causes a server crash.

I'm not able to reproduce this on my 855GM with 2.1.99 driver, also not reproducible on 915gm/945gm with git tip driver.

Ok, let's try it more detailed:
1) mplayer -vo xv -ao alsa some_viod.avi
2) Switch to konsole/xterm etc. (I'm on konsole), so mplayer window is completely hidden by konsole window. (I use Alt + Tab)
3) Ctrl + Z
4) bg
5) 2 x cursor up (so you get the command again.
6) Enter
7) Now make mplayer visible by a mouse click on task bar.

I'm sure I got it with simpler ways too, but I guess the problem is the xv window in the background while trying to open the second xv.

Note that reproduceablity is still sometimes (30 %), not always, I'm trying to work out if it has to do with the mouse pointer position.

It hope I'm now at 100 % reproduceability:

1) mplayer -vo xv -ao alsa somevid.avi
2) Alt + Tab to go back to console
3) Ctrl + Z
4) Wait 15 seconds
5) fg
6) Now bring mplayer window in foreground
7) Crash

What we need is a new title for the bug.

As an additional note: If the konsole window does not completely hide the mplayer window, I get screen corruption instead.

It's even simpler: You just need to completely hide the mplayer window for more than 10 (even less might be enough) seconds you don't need to stop mplayer.

(In reply to comment #11)
> It hope I'm now at 100 % reproduceability:

After this (but using Totem instead) I am able to reproduce this on DELL Latitude D820 with Intel 945GM. Started happening when Ubuntu Hardy (current dev release) switched to version 2.1.99 of the "intel" X.org driver.

It's pretty annoying, so if I can do anything (non-dev :)) to help fix this, just let me know.

(In reply to comment #14)

Backtraces might be useful. http://wiki.debian.org/XStrikeForce/XserverDebugging

Just a non-dev opinion.

BTW: Do you also see the screen corruption when the XV window is half-hidden?

(In reply to comment #15)
> Backtraces might be useful.
> http://wiki.debian.org/XStrikeForce/XserverDebugging

I'll try to provide some later.

> BTW: Do you also see the screen corruption when the XV window is half-hidden?

No screen corruption until the crash. When it crashes, it sometimes restarts back to the GDM screen, sometimes I see some full-screen screen corruption... wierd lines, dots and such. At that point the system does not react to any key presses, so it needs a cold start.

In reply to comment #11)
> It hope I'm now at 100 % reproduceability:
Using Willi's method,I can reporduce this bug 0n my 855gm machine with intel-2.2.0 driver.but I can not reproduce this bug on 945gm with latest git code.Interestingly,only when full-cover the mplayer window with console window,then can reproduce this bug and it's just xserver crash,not the whole system(although apparently the keyboard has no response,in fact it has, only you do VT switch this time that can crash the whole system)

back trace on my 855gm
Backtrace:
0: X(xf86SigHandler+0x80) [0x80d0850]
1: [0xffffe420]
2: X [0x80df45b]
3: /opt/X11R7/lib/xorg/modules/extensions//libextmod.so(XvdiPutImage+0x17d) [0xb7ea588d]
4: /opt/X11R7/lib/xorg/modules/extensions//libextmod.so [0xb7ea83fc]
5: X [0x81483ed]
6: X(Dispatch+0x357) [0x8087597]
7: X(main+0x490) [0x806e2d0]
8: /lib/libc.so.6(__libc_start_main+0xdc) [0x6657e4]
9: X(FontFileCompleteXLFD+0xa1) [0x806d821]

Fatal server error:
Caught signal 11. Server aborting

> you do VT switch this time that can crash the whole system)

I'm in no way experiencing full system crashes, but I have NoTrapSignals On, as I always ended up with a frozen system when I experienced the recently fixed VT-switch bug and had NoTrapSignals off. Also, it's much simpler to get backtraces.

What surprises me is that your backtrace ends in xf86sighandler, mine always end in some memory related function, in libc, or in the kernel.

moreover,on 915gm using the same environment just as my 855gm,it seems there is no this bug problem.

(In reply to comment #20)
> moreover,on 915gm using the same environment just as my 855gm,it seems there is
> no this bug problem.

Don't the 9xx chips allow for more than one XV playing method? If so, did you try with other than the default port? On 855GM, I only have port 73, Adaptor #0: "Intel(R) Video Overlay", according to xvinfo.

In reply to comment #21)

Yes, On the 9xx(<965) chips there are two XV playing method:"Intel(R) Textured Video" and "Intel(R) Video Overlay". On my 915gm, the default XV playing method is "Intel(R) Textured Video" and using this default option can not reproduce this bug.When switch to "Intel(R) Video Overlay",the bug can reproduce everytime.Moreover,under "Intel(R) Video Overlay",using intel-2.2.0 driver can reproduce this bug,if using latest git code can not reproduce. So,my conclusion is:using intel-2.2.0 with "Intel(R) Video Overlay" XV playing method can reproduce this bug.

(In reply to comment #22)
> using intel-2.2.0 driver can
> reproduce this bug,if using latest git code can not reproduce. So,my conclusion

Do you mean latest git of everything or just latest git of intel driver? I ask because the difference on the intel driver is just TV out related, so it seems unlikely to be really fixed. (And I can reproduce it with latest intel driver git on 855GM)

http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=summary

(In reply to comment #23)
yeah,my old conclusion is wrong.I do more detailed testing again:
I used the xserver 1.4 with latest git source code or relese version driver(intel-2.2.0) both can reproduce this bug.When I used xserver git source with latest intel git source code or release version driver(intel-2.2.0) can not reproduce this bug. So this bug is not intel dirver’s problem.Willi,You can try using the latest xserver git source code and see if this problem gone or not.

Using what's currently in debian unstable (2:1.4.1~git20071119-1), I can still reproduce this bug. I could test latest git, but that would take some time.

Created an attachment (id=12725)
latest version of crash backtrace

(In reply to comment #24)
Just to ensure we do the same when we try to reproduce the bug, could you describe how you do it exactly? (I'm especially interested in the timing and the video you use)
What I do is:
1) mplayer -vo xv some_vid.avi
   (the video I use is 720x544, I can't share because of the size and possible copyright issues)
2) put konsole window in foreground - best is probably to ensure before 1) that it covers the whole screen (except taskbar in my case).
3) Wait 20 seconds (10 seems to be enough but I usually wait 20 seconds to be on the "safe" side)
4) bring mplayer window into foreground and let the crash happen.

I can reproduce this on FJS Amilo Pi1505 with Intel GMA950 - hiding Mplayer with XV video overlay for more than ~10 seconds and then bringing it to foreground or quitting mplayer crashes xserver. Textured video doesn't crash (but tears instead :) ). I'm running Debian unstable with latest repo xorg and driver.
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c660e]
1: [0xffffe420]
2: /lib/i686/cmov/libc.so.6(vsnprintf+0xb4) [0xb7d9f874]
3: /usr/bin/X(LogVWrite+0xb7) [0x81bac47]
4: /usr/bin/X(LogVMessageVerb+0x99) [0x81bb189]
5: /usr/bin/X(xf86VDrvMsgVerb+0xda) [0x80d01ca]
6: /usr/bin/X(xf86DrvMsg+0x3d) [0x80d11ad]
7: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b72207]
8: /usr/lib/xorg/modules/drivers//intel_drv.so(i830_free_memory+0x24) [0xb7b72fa
4]
9: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b77d87]
10: /usr/bin/X [0x80d94f5]
11: /usr/lib/xorg/modules/extensions//libextmod.so(XvdiPutImage+0x178) [0xb7c226
d8]
12: /usr/lib/xorg/modules/extensions//libextmod.so [0xb7c25546]
13: /usr/bin/X [0x814d58e]
14: /usr/bin/X(Dispatch+0x2bf) [0x808d1ff]
15: /usr/bin/X(main+0x48b) [0x807474b]
16: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7d53450]
17: /usr/bin/X(FontFileCompleteXLFD+0x20d) [0x8073ac1]

Created an attachment (id=13087)
latest backtrace

As I said ealier, backtraces vary a little bit, but the I830PutImage is always involved. Note that yesterday I found bug in the debian BTS that describes a similar issue with the ati driver. http://bugs.debian.org/455837

What I wanted to post before but didn't is:
I can still reproduce this bug with the latest debian packages 2:1.4.1~git20071212-1 of xserver and latest git of intel driver.

I've had a (similar?) crash several times running Ubuntu Hardy, with xserver 2:1.4.1~git20071119-1ubuntu1 and the -intel driver 2:2.2.0-1ubuntu1.

I've put a couple of backtraces in https://launchpad.net/bugs/173265 - the way to get the crash was similar - opening a video in totem, hiding it, and bringing it to the top a few seconds later.

I have an Intel gma 915 mobile:
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)

Created an attachment (id=13192)
Possible fix

This seems to fix the problem here, can you confirm?

(In reply to comment #32)

> This seems to fix the problem here, can you confirm?

Yes, it does. Thanks for the patch.

At line 2688, there is another free on pPriv->buf that's not set to NULL. Just noting that as I remember there were similar fixes for 2.2.

(In reply to comment #33)
> At line 2688, there is another free on pPriv->buf that's not set to NULL.

Thanks. Fixes pushed to master branch, but leaving open for the 2.2.1 tracker.

Seems to work fine on my i855GM, I'll push this patch to Gentoo to see if it helps more users.

Thanks to all for the patch.

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

Pulled fix into 2.2 branch.