MPlayer raise SIGABRT on -mm Kernel

Karimo · 05-16-2008, 10:12 AM

Hi everybody!
Since my compile of a 2.6.25-mm1 Linux Kernel on a Slackware-current I'm experiencing a very annoying issue:
when I start mplayer on a simple avi video (DivX/XviD) under X11 running the brand new 2.6.25-mm1 it hangs receiving a SIGABRT (6); this is the output of the console:

Code:

AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 720 x 416 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.73:1 - prescaling to correct movie aspect.
VO: [xv] 720x416 => 720x416 Planar YV12 
X11 error: BadAccess (attempt to access private resource denied)


MPlayer interrupted by signal 6 in module: decode_video
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.

When I've seen that "denied" immediately I tried playing the same file under root...same result!
The strange thing is that under my previous vanilla kernel (2.6.23) mplayer works fine on the same file.
Although the -mm kernel seems to work great except this damn strange problem.
I'm wondering if you can give me a hand to solve this issue.
Thanks a Lot.

Karimo

Bruce Hill · 05-16-2008, 07:43 PM

From the Slackware CHANGES_AND_HINTS.TXT:

Code:

Use one of the provided generic kernels for daily use.  Do not report
  bugs until/unless you have reproduced them using one of the stock
  generic kernels.  You will need to create an initrd in order to boot
  the generic kernels - see /boot/README.initrd for instructions.

Have you first filed a bug report with MPlayer as your output suggests?

You're also using a dated kernel. 2.6.25.4 is the latest stable.

andrew.46 · 05-17-2008, 01:38 AM

Hi,

You could approach mplayer-users but you will need to be running the latest svn to get a sympathetic response. Which version are you running?

Andrew

Karimo · 05-17-2008, 06:53 AM

Quote:

Originally Posted by Bruce Hill

From the Slackware CHANGES_AND_HINTS.TXT:

Code:

Use one of the provided generic kernels for daily use.  Do not report
  bugs until/unless you have reproduced them using one of the stock
  generic kernels.  You will need to create an initrd in order to boot
  the generic kernels - see /boot/README.initrd for instructions.

Have you first filed a bug report with MPlayer as your output suggests?

You're also using a dated kernel. 2.6.25.4 is the latest stable.

AHW! What a Hint :S! The -mm series is not so experimental for daily use though.
I have to try compiling the vanilla 2.6.25 kernel and let mplayer running it up and see if the bug is going to come out again.

Mplayer version:

Code:

MPlayer 1.0pre8-3.4.6 (C) 2000-2006 MPlayer Team
CPU: AMD Athlon(tm) XP 2000+ (Family: 6, Model: 10, Stepping: 0)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

It's not so recent :S...but compiling mplayer under -mm with modified headers is not so simple (I have to find the will xD).
I'll try with a more recent vanilla kernel: I'll tell you after this experiment.
I'd like any other suggestions

vadkutya · 05-17-2008, 01:45 PM

Quote:

compiling mplayer under -mm with modified headers is not so simple

you will have to do so. this is most likely no bug in mplayer code. if the new kernel works flawlessly you should recompile mplayer. this shoudn't be too complicate.

were you compiling mplayer for you're vanilla kernel? if so then it's tailormade for your vanilla kernel and simply doesn't work properly with the new one. if not still do a recompile. it will most surely solve your problem

good luck, vadkutya

Karimo · 05-18-2008, 05:34 AM

Compiled a brand new 2.6.25.4 vanilla kernel, compiled latest MPlayer

Code:

MPlayer 1.0rc2-4.2.3 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 2000+ (Family: 6, Model: 10, Stepping: 0)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

with the 2.6.25.4 headers of course. I tried running it up the new vanilla kernel...

SAME PROBLEM! I'm trying to figure out the problem in some fb/drm driver of the linux kernel...but it seems too strange for me...
Suggestions?

vadkutya · 05-18-2008, 06:53 AM

hey karimo,

can you please give verbose output of mplayer trying to play a file? this might help. also, what video card do you use? x32 or x64 arch? which runlevel: 3 or 5? which user/group? try running it as root...

thx, vadkutya

Karimo · 05-18-2008, 08:49 AM

Quote:

Originally Posted by vadkutya

hey karimo,

can you please give verbose output of mplayer trying to play a file? this might help. also, what video card do you use? x32 or x64 arch? which runlevel: 3 or 5? which user/group? try running it as root...

thx, vadkutya

read better all my previous posts: there you'll find answers to yours questions.

I've Solved the Problem guys! The problem was on shm handling.
After some gdb tweaking I figured out that mplayer received a SIGSEGV in a memset call on vo_vx.c:444 and I found that the memory space passed to the memset call was allocated by some Shm functions in case of ENABLE_SHM constant. I tried so to disable shm in the mplayer configure through --disable-shm and mplayer works fine now.
The real question is not solved though: MPlayer have some problem to manage --enable-shm on Linux Kernel>=2.6.25: Is there a kernel's configuration related to shm? (Maybe "Sparse Memory" instead of "Flat Memory" cause some allocation problem on /dev/shm? I'll try some different Kernel compilations soon).