| Summary: | Crash after killing mplayer | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Clemens Eisserer <linuxhippy> |
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | chris |
| Version: | unspecified | Keywords: | NEEDINFO |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Well, maybe the crash itself has something to do with bug#24274, however the weird behaviour after killing mplayer is not mentioned there (and I guess there is a correlation between those two). After mplayer has been killed, the system isn't useable at all. definitely doesn't look like #24274 Clemens, very odd symptoms. I guess the actual crash is just another symptom of the strange behaviour. Do you have a small video file that shows corruption and triggers this behaviour? Hmm, maybe I could just fuzz a video file and see what happens. What video output device is mplayer using? Xv, xvmc, x11, one of the GLs? Thanks. Eeek, just tried big_buck_bunny_720p_stereo.ogg with mplayer and now I live in interesting times. Various forms of screen flicker and stutter, but no errors being reported -- all this without even trying a corrupted video file and suffering a mplayer hang. Well the bad news is that the flicker is unrelated to mplayer. It just happened to be a coincidence that the first time it struck was after closing mplayer. It's happened again after an idle session, never having run mplayer. Clemens, any details on the corrupt files that trigger the mplayer death and misbehaviour? Ok, I think I've found and fixed some related issues in the error handling between drm and the ddx. The prime candidate for this one would be the lack of accurate error detection after a failure to map the drawable, which would trigger a segfault like seen here. That error path would only be triggered when running short of memory, which I suspect is true in case since the "slow system" could well be due to swap thrashing. libdrm: commit acb4aa671507aa181b3ff50ccf26a1c0d705a309 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Dec 2 12:40:26 2009 +0000 intel: Review use of errno. Hitting this error lead to a segfault: intel_bufmgr_gem.c:919: Error mapping buffer 48607 (pixmap): Cannot allocate memory. because the errno was reused as the function return value after being reset by the fprintf(), so caller thought the mapping had succeeded. The convention established by libdrm is that the return value is the negative errno and that uses of libdrm cannot trust the value of errno afterwards, but must use the return code. Clemens, I *think* I've fixed this and associated errors, but please reopen if you do hit something like this again. Thanks for taking a look. I'll re-open if I encounter the problem again. |
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.
When playing corrupted video files, mplayer sometimes gets stuck. Killing such a hung mplayer using Alt+Ctrl+Esc a few times, suddenly results in an extremly slow system (mouse movement is fine, everything else is *extremly* slow) followed a crash 2-3min after. I can perfectly trigger this problem. My system is fedora rawhide running: - i945GM - intel-2.8.99 - Xorg-1.7 - Kernel 2.6.31 When it died last time, I got this stack-trace: Program received signal SIGSEGV, Segmentation fault. 0x00507567 in fbSolid (dst=<value optimized out>, dstStride=<value optimized out>, dstX=<value optimized out>, bpp=1, width=6, height=<value optimized out>, and=0, xor=4294967295) at fbsolid.c:65 65 FbDoLeftMaskByteRRop(dst,startbyte,startmask,and,xor); (gdb) bt #0 0x00507567 in fbSolid (dst=<value optimized out>, dstStride=<value optimized out>, dstX=<value optimized out>, bpp=1, width=6, height=<value optimized out>, and=0, xor=4294967295) at fbsolid.c:65 #1 0x00500285 in fbFill (pDrawable=<value optimized out>, pGC=<value optimized out>, x=<value optimized out>, y=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at fbfill.c:53 #2 0x00500650 in fbPolyFillRect (pDrawable=<value optimized out>, pGC=<value optimized out>, nrect=<value optimized out>, prect=<value optimized out>) at fbfillrect.c:77 #3 0x005dedaa in uxa_check_poly_fill_rect (pDrawable=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- pGC=<value optimized out>, nrect=<value optimized out>, prect=<value optimized out>) at uxa-unaccel.c:257 #4 0x005d8fdd in uxa_poly_fill_rect (pDrawable=<value optimized out>, pGC=<value optimized out>, nrect=<value optimized out>, prect=<value optimized out>) at uxa-accel.c:727 #5 0x005d7c14 in uxa_poly_segment (pDrawable=<value optimized out>, pGC=<value optimized out>, nseg=<value optimized out>, pSeg=<value optimized out>) at uxa-accel.c:658 #6 0x0811cb62 in damagePolySegment (pDrawable=<value optimized out>, pGC=<value optimized out>, nSeg=<value optimized out>, pSeg=<value optimized out>) ttcc ---Type <return> to continue, or q <return> to quit--- at damage.c:1191 #7 0x0806c0d0 in ProcPolySegment (client=<value optimized out>) at dispatch.c:1855 #8 0x0806e167 in Dispatch () at dispatch.c:445 #9 0x08062855 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285