Created attachment 55705 [details] Backtrace of X crash I just built a mythtv media server running Debian (wheezy) based on the intel HD3000 graphics built-in to the i3-2105. lspci reports it as: $ sudo lspci -vnn -s 00:02.00 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0112] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:844d] Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at fb000000 (64-bit, non-prefetchable) [size=4M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 At first, the GPU would hang when I played certain recordings. However, on the advice of the Debian maintainers I upgraded to the latest and greatest: $ dpkg -l xserver\* | grep ^i ii xserver-common 2:1.11.99.901-1 common files used by various X servers ii xserver-xorg 1:7.6+10 X.Org X server ii xserver-xorg-core 2:1.11.99.901-1 Xorg X server - core server ii xserver-xorg-core-dbg 2:1.11.99.901-1 Xorg - the X.Org X server (debugging symbols) ii xserver-xorg-input-evdev 1:2.6.99.901-1 X.Org X server -- evdev input driver ii xserver-xorg-video-fbdev 1:0.4.2-7 X.Org X server -- fbdev display driver ii xserver-xorg-video-intel 2:2.17.0+git20120115-1 X.Org X server -- Intel i8xx, i9xx display driver ii xserver-xorg-video-intel-dbg 2:2.17.0+git20120115-1 X.Org X server -- Intel i8xx, i9xx display driver (debug symbols) ii xserver-xorg-video-vesa 1:2.3.0-7+exp1 X.Org X server -- VESA display driver Now, the X server just crashes when I play those same recordings. I can reproduce this at will, and am attaching a full backtrace. Please let me know if there's any other information you need.
Oh, in case you're wondering about which kernel I'm running it is: $ uname -srvmo Linux 3.2.0-rc7-amd64 #1 SMP Wed Dec 28 14:29:59 UTC 2011 x86_64 GNU/Linux
I think we have memory corruption here, or something equally bizarre. The toplevel carefully validates the input before calling the midlevel CreateContext function. So unless there is a frame missing from the backtrace, crashing on that function pointer dereference is mighty suspicious. Are you able to launch X by hand, start mythtv and reproduce the issue? (e.g. X -ac -noreset & sleep 3; DISPLAY=:0 mythtv) Can you try running X under valgrind? That usually requires you to cp /usr/bin/Xorg /tmp; valgrind --trace-children=yes /tmp/X -ac -noreset.
Hi Chris, On Wed, Jan 18, 2012 at 11:01:55AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=44874 > > --- Comment #2 from Chris Wilson <chris@chris-wilson.co.uk> 2012-01-18 03:01:55 PST --- > Are you able to launch X by hand, start mythtv and reproduce the issue? > (e.g. X -ac -noreset & sleep 3; DISPLAY=:0 mythtv) Can you try running X under > valgrind? That usually requires you to cp /usr/bin/Xorg /tmp; valgrind > --trace-children=yes /tmp/X -ac -noreset. I ran under valgrind as you suggested and this is what I got: ==4071== Invalid read of size 8 ==4071== at 0x1AF1D5: xf86XvMCCreateContext (xf86xvmc.c:78) ==4071== by 0x7CD0506: ProcXvMCCreateContext (xvmc.c:243) ==4071== by 0x15AA40: Dispatch (dispatch.c:437) ==4071== by 0x1499E9: main (main.c:287) ==4071== Address 0x7ff0002d8 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==4071== ==4071== Invalid read of size 8 ==4071== at 0x1AF1D9: xf86XvMCCreateContext (xf86xvmc.c:78) ==4071== by 0x7CD0506: ProcXvMCCreateContext (xvmc.c:243) ==4071== by 0x15AA40: Dispatch (dispatch.c:437) ==4071== by 0x1499E9: main (main.c:287) ==4071== Address 0x29 is not stack'd, malloc'd or (recently) free'd ==4071== ==4071== ==4071== Process terminating with default action of signal 11 (SIGSEGV) ==4071== General Protection Fault ==4071== at 0x6939EE0: __sprintf_chk (sprintf_chk.c:28) ==4071== by 0x29B19C: LogVWrite (stdio2.h:34) ==4071== by 0x29AEBB: ErrorF (log.c:636) ==4071== by 0x2900F8: xorg_backtrace (backtrace.c:46) ==4071== by 0x293C98: OsSigHandler (osinit.c:129) ==4071== by 0x56D602F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.13.so) ==4071== by 0x1AF1D8: xf86XvMCCreateContext (xf86xvmc.c:78) ==4071== by 0x7CD0506: ProcXvMCCreateContext (xvmc.c:243) ==4071== by 0x15AA40: Dispatch (dispatch.c:437) ==4071== by 0x1499E9: main (main.c:287) ==4071== ==4071== HEAP SUMMARY: ==4071== in use at exit: 4,358,898 bytes in 12,911 blocks ==4071== total heap usage: 60,103 allocs, 47,192 frees, 10,069,623 bytes allocated ==4071== ==4071== LEAK SUMMARY: ==4071== definitely lost: 6,258 bytes in 39 blocks ==4071== indirectly lost: 463,187 bytes in 59 blocks ==4071== possibly lost: 7,538 bytes in 114 blocks ==4071== still reachable: 3,881,915 bytes in 12,699 blocks ==4071== suppressed: 0 bytes in 0 blocks ==4071== Rerun with --leak-check=full to see details of leaked memory ==4071== ==4071== For counts of detected and suppressed errors, rerun with: -v ==4071== Use --track-origins=yes to see where uninitialised values come from ==4071== ERROR SUMMARY: 6042 errors from 39 contexts (suppressed: 2 from 2) Segmentation fault Does this help? What next? --Joe
Created attachment 55761 [details] valgrind output I ran under valgrind as you suggested and this is what I got: ==4071== Invalid read of size 8 ==4071== at 0x1AF1D5: xf86XvMCCreateContext (xf86xvmc.c:78) ==4071== by 0x7CD0506: ProcXvMCCreateContext (xvmc.c:243) ==4071== by 0x15AA40: Dispatch (dispatch.c:437) ==4071== by 0x1499E9: main (main.c:287) ==4071== Address 0x7ff0002d8 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==4071== ==4071== Invalid read of size 8 ==4071== at 0x1AF1D9: xf86XvMCCreateContext (xf86xvmc.c:78) ==4071== by 0x7CD0506: ProcXvMCCreateContext (xvmc.c:243) ==4071== by 0x15AA40: Dispatch (dispatch.c:437) ==4071== by 0x1499E9: main (main.c:287) ==4071== Address 0x29 is not stack'd, malloc'd or (recently) free'd ==4071== ==4071== ==4071== Process terminating with default action of signal 11 (SIGSEGV) ==4071== General Protection Fault ==4071== at 0x6939EE0: __sprintf_chk (sprintf_chk.c:28) ==4071== by 0x29B19C: LogVWrite (stdio2.h:34) ==4071== by 0x29AEBB: ErrorF (log.c:636) ==4071== by 0x2900F8: xorg_backtrace (backtrace.c:46) ==4071== by 0x293C98: OsSigHandler (osinit.c:129) ==4071== by 0x56D602F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.13.so) ==4071== by 0x1AF1D8: xf86XvMCCreateContext (xf86xvmc.c:78) ==4071== by 0x7CD0506: ProcXvMCCreateContext (xvmc.c:243) ==4071== by 0x15AA40: Dispatch (dispatch.c:437) ==4071== by 0x1499E9: main (main.c:287) Full log is attached. Does this help? What next?
Can you please attach your Xorg.log? In particular I'm interested in seeing whether XvMC failed to initialise. My theory is that you have hit this bug: http://cgit.freedesktop.org/~ickle/xserver/commit/?id=1c96157cf921a4a0fde5d373c522033369a64bfb
Created attachment 56208 [details] Xorg log file from latest crash Attaching Xorg.log from latest crash.
That disproves that theory. Is there any chance you can compile your own ddx and include ./configure --enable-sna --enable-debug=full and attach the full log. I'm trying to put together the sequence of events that leads to the crash, trying to establish how we end up with a dangling pointer in the XvMC adaptors.
Do you have an example of which movies trigger the crash? And is this reproduce with just mplayer?
Hi Chris, On Fri, Jan 27, 2012 at 11:39:59AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=44874 > > --- Comment #8 from Chris Wilson <chris@chris-wilson.co.uk> 2012-01-27 03:39:59 PST --- > Do you have an example of which movies trigger the crash? And is this > reproduce with just mplayer? Yes, I have examples movies that trigger the crash, but they're rather large :) If I play the same file in vlc, it does NOT crash. Also, talking to a mythtv person, they have a setting called Video Playback Profile. If I change it, it supposedly disables XvMC which fixes the problem as well. --Joe
Hmm. Reading through src/xvmc it doesn't handle SNB, yet as far as I can tell UXA is also trying to enable xvmc for SNB. But that doesn't explain why it causes a crash! (Except that I would expect a GPU hang if you tried to use it.) commit 22e452ebe01c32a08599411743cf18f9ad0545a7 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Feb 6 09:19:56 2012 +0000 sna: Disable use of xvmc for SNB+ Not yet implemented, so don't bother setting it to fail. References: https://bugs.freedesktop.org/show_bug.cgi?id=44874 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I believe that the patch to disable attempting to XvMC will be sufficient to prevent the crash, and as it remains an unimplemented feature (not even sure if there is hw mc on snb...) it will remain disabled for some time.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.