(g)mplayer crashes/freezes and reboots ...

DutchDaemon

DutchDaemon

Administrator
Staff member
Administrator
Moderator
Developer
Wondering if anyone else has witnessed this: when playing video with mplayer or gmplayer, skipping forward or backward, either by using the arrow keys (mplayer, gmplayer) or by clicking in the progress slider (gmplayer), will eventually lead to a lock-up of my laptop, and a reboot 10-15 seconds later.

I can usually get away with skipping a few times, but there's an inevitable 'one time too many'. It even happens when playing video with gimv (which uses mplayer 'internally', I believe. When playing video using the USB system (stick, drive), a single skip is enough: boom.

I have installed VLC again to test, but that doesn't give me any grief when using 'Ctl ->' or 'Ctl <-'.

Has anyone else seen similar behaviour? If not, I'll have to delve into the vmcores in /var/crash, I guess.
 
Look, how can I guess what Xorg, dri, libdrm, Mesa, libGL,.. ports version you are using and what xf86-video-* is it about.

When such behavior started happening ... and etc.

From my memory of reading Xorg mailing list recent Intel drivers had such nice feature, I'm not going to delve into details ...

I doubt that Xorg developers (most of them are paid to work on linux for linux) would be interested in FreeBSD crash core.
 
Look, I am not asking you or anyone else to explain what's happening, nor am I pointing to Xorg, dri, libdrm, etc. I'm merely asking whether other people are having similar problems with mplayer. If not, I will try to analyse my core. Period. Jeez.
 
It is obvious to me that problem is not in FreeBSD, so analyzing core dump will gain nothing.
I hope that core files are generated at all :)

It could be also irq thingy but you provide so much details that I really can't help you.
 
Thanks, but it doesn't look like my problem. (g)Mplayer itself starts fine, works fine, plays whatever I want from start to finish, but only when I leave it alone. As soon as I start skipping around it freezes, sometimes after 3 skips, sometimes after 30.

I guess what I'm trying to achieve is either a series of replies stating that skipping works for everyone else, so I can concentrate on local problems/settings/hardware only, or replies that report the same problem, so we can find out what settings/hardware we have in common and find the lowest common denominator to focus on.

At this point in the process replies like 'try setting x to y' or 'try waving a red flag out of the window' will not be of much use to me ;)

All I can add right now is that I'm on a very recent 32-bit STABLE with NVIDIA blob, and that all ports are up-to-date as of today.
 
Mine experience with mplayer (both prehistoric and svn version) is very good. It never managed to crash Xorg(not mentioning FreeBSD).
And I skip frames all the time when watching youtube videos.
Not just that small youtube videos but also huge others ones that can not fit on 1280x800 screen ....
 
Since this thread is open, I would like to point to one other bug. It's in libass (subtitles), when you play a large file with subtitles, your memory is filled till the end (memory leak) and FreeBSD freezes. It's not solved in the ports yet, however it's fixed in newer mplayer versions.

http://bugs.gentoo.org/213638
 
DutchDaemon said:
when playing video with mplayer or gmplayer, skipping forward or backward, either by using the arrow keys (mplayer, gmplayer) or by clicking in the progress slider (gmplayer), will eventually lead to a lock-up of my laptop, and a reboot 10-15 seconds later.

I can usually get away with skipping a few times, but there's an inevitable 'one time too many'.
Click to expand...
I remember seeing lockups on seeking several times without delays inbetween. It was around 2 years ago on 6-stable on i386 + binary blob on GF FX 5800. IIRC, I couldn't reproduce it using xf86-video-nv.

But nowadays I use 8-current on amd64, Xorg-git, nouveau on GF 9600 GT, mplayer-svn and can't reproduce the lockup on seeking.
 
Ok, I'm gonna go with 'strictly local problem' here. VLC does not cause any problems while 'skipping', but it crashes and reboots my laptop at the end of a fullscreen video (when it's supposed to close and exit). I think I'm going to grab me a new stable and rebuild video related ports after that. Thanks to those who responded.
 
OT:
May I ask how do you compile the SVN version ? Do you apply any patches at all ? The standard way (configure && gmake) fails for me.
 
hydra, I use gcc45 + binutils-2.19 (for SSSE3, from devel/cross-binutils) and these hacks
Code: 
Index: vidix/pci.c
===================================================================
--- vidix/pci.c	(revision 29317)
+++ vidix/pci.c	(working copy)
@@ -481,8 +481,6 @@
 #include "sysdep/pci_arm32.c"
 #elif defined(__powerpc__)
 #include "sysdep/pci_powerpc.c"
-#elif defined(__x86_64__) || defined(__sh__)
-/* Nothing here right now */
 #else
 #include "sysdep/pci_x86.c"
 #endif
Index: configure
===================================================================
--- configure	(revision 29317)
+++ configure	(working copy)
@@ -2410,7 +2410,7 @@
   elif test "$cc_vendor" != "gnu" ; then
     CFLAGS="-O2 $_march $_mcpu $_pipe"
   else
-    CFLAGS="-Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 $_march $_mcpu $_pipe -ffast-math -fomit-frame-pointer"
+    CFLAGS="-Wall -Wno-switch -Wpointer-arith -Wredundant-decls -combine -s -O4 -msse4.1 -fno-strict-aliasing -Wl,--as-needed $_march $_mcpu $_pipe -ffast-math -fomit-frame-pointer"
     extra_ldflags="$extra_ldflags -ffast-math"
   fi
 else
@@ -7750,7 +7750,7 @@
   if darwin ; then
      extra_ldflags="$extra_ldflags ${_xmmslibdir}/libxmms.dylib"
   else
-     extra_ldflags="$extra_ldflags ${_xmmslibdir}/libxmms.so.1 -export-dynamic"
+     extra_ldflags="$extra_ldflags ${_xmmslibdir}/libxmms.so.4 -lintl -export-dynamic"
   fi
 else
   def_xmms='#undef CONFIG_XMMS'
@@ -7765,7 +7765,7 @@
 
   # Required libraries
   if test "$_libavcodec" != yes ||
-      ! echo $_libavdecoders | grep -q PNG_DECODER ; then
+      echo $_libavdecoders | ! grep -q PNG_DECODER ; then
     die "The GUI requires libavcodec with PNG support (needs zlib)."
   fi
   test "$_freetype" = no && test "$_bitmap_font" = no && \
Index: mp_msg.c
===================================================================
--- mp_msg.c	(revision 29317)
+++ mp_msg.c	(working copy)
@@ -221,5 +221,6 @@
     header = tmp[strlen(tmp)-1] == '\n' || tmp[strlen(tmp)-1] == '\r';
 
     fprintf(stream, "%s", tmp);
+    fprintf(stream, "\033[m");
     fflush(stream);
 }
(note: you should remove -msse4.1)

and compile it like
[cmd=">"]./configure --enable-gui[/cmd] (though, I don't use GUI)
[cmd=">"]gmake -j3[/cmd]
 
Thanks blah, but I got errors from libavc, I will just live with the leak until it's fixed, or find a solution and commit.
 
hydra, if you're using old compiler/assembler from base you're likely bump into these while compiling libavcodec
Code: 
{standard input}:36151: Error: `ff_h264_mlps_state+128(%eax)' is not a valid 64 bit base/index expression
{standard input}:36163: Error: `-1(%ebx)' is not a valid 64 bit base/index expression
{standard input}:36166: Error: `ff_h264_norm_shift(%ecx)' is not a valid 64 bit base/index expression
{standard input}:36185: Error: `ff_h264_lps_range(%eax,%esi,2)' is not a valid 64 bit base/index expression
{standard input}:36195: Error: `ff_h264_norm_shift(%esi)' is not a valid 64 bit base/index expression
{standard input}:36197: Error: `ff_h264_mlps_state+128(%eax)' is not a valid 64 bit base/index expression
which you can workaround by -DBROKEN_RELOCATIONS like it's done in multimedia/mplayer.
 
Yeah, exactly, I get those kinds of errors, however I couldn't manage to fix it, I'll try later, thanks for the help blah anyways.
 
Right, to return to the original topic for a minute ... After (g)mplayer and vlc crashed and rebooted my laptop, I found that xmms did that as well. It did so specifically when skipping between tracks (mp3 tracks).

So the lowest common denominator turned out to be audio; also because crash and dmesg information got written to /var/log/soundon.log, which is not very typical ... I managed to cross-reference the crash information (page faults) with an irq, and the irq with loaded OSS (Open Sound System from ports) modules.

After unloading the two OSS kernel modules and reverting back to snd_hda ... no more crashes.
 
FWIW I noticed that my mplayer seems quite prone to crashing these days. Since I also use OSS this might be related. Both OSS and mplayer are up to date.

No reboots though, just crashes. Quite frequently unfortunately.
 
Also on 'skipping' activity, or even when everything is playing without user interruption? With me, it was only the skipping stuff (post #17), and it hasn't happened since I abandoned the OSS from ports. I'm not sure whether I was on FreeBSD 7 or 8 at the time, so mileages may vary.
 
Thanks, I may give it another try, though FreeBSD 8's OSS layer works fine as it is.
 
DutchDaemon said:
Thanks, I may give it another try, though FreeBSD 8's OSS layer works fine as it is.
Click to expand...

Just to follow up on this: ran OSS 4.1-build1052 from ports on 8.0-BETA4 today, and skipping through a video crashed the system again. Not a spontaneous reboot this time, but a hard lock-up; power cycle needed. Back to snd_hda once again ..
 
DutchDaemon said:
Also on 'skipping' activity, or even when everything is playing without user interruption? With me, it was only the skipping stuff (post #17), and it hasn't happened since I abandoned the OSS from ports. I'm not sure whether I was on FreeBSD 7 or 8 at the time, so mileages may vary.
Click to expand...

It seems to occur mainly when I skip though files. I'm on 7.2-STABLE.
 
blah said:
hydra, I use gcc45 + binutils-2.19 (for SSSE3, from devel/cross-binutils) and these hacks
Code: 
Index: vidix/pci.c
===================================================================
--- vidix/pci.c	(revision 29317)
+++ vidix/pci.c	(working copy)
@@ -481,8 +481,6 @@
 #include "sysdep/pci_arm32.c"
 #elif defined(__powerpc__)
 #include "sysdep/pci_powerpc.c"
-#elif defined(__x86_64__) || defined(__sh__)
-/* Nothing here right now */
 #else
 #include "sysdep/pci_x86.c"
 #endif
Index: configure
===================================================================
--- configure	(revision 29317)
+++ configure	(working copy)
@@ -2410,7 +2410,7 @@
   elif test "$cc_vendor" != "gnu" ; then
     CFLAGS="-O2 $_march $_mcpu $_pipe"
   else
-    CFLAGS="-Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 $_march $_mcpu $_pipe -ffast-math -fomit-frame-pointer"
+    CFLAGS="-Wall -Wno-switch -Wpointer-arith -Wredundant-decls -combine -s -O4 -msse4.1 -fno-strict-aliasing -Wl,--as-needed $_march $_mcpu $_pipe -ffast-math -fomit-frame-pointer"
     extra_ldflags="$extra_ldflags -ffast-math"
   fi
 else
@@ -7750,7 +7750,7 @@
   if darwin ; then
      extra_ldflags="$extra_ldflags ${_xmmslibdir}/libxmms.dylib"
   else
-     extra_ldflags="$extra_ldflags ${_xmmslibdir}/libxmms.so.1 -export-dynamic"
+     extra_ldflags="$extra_ldflags ${_xmmslibdir}/libxmms.so.4 -lintl -export-dynamic"
   fi
 else
   def_xmms='#undef CONFIG_XMMS'
@@ -7765,7 +7765,7 @@
 
   # Required libraries
   if test "$_libavcodec" != yes ||
-      ! echo $_libavdecoders | grep -q PNG_DECODER ; then
+      echo $_libavdecoders | ! grep -q PNG_DECODER ; then
     die "The GUI requires libavcodec with PNG support (needs zlib)."
   fi
   test "$_freetype" = no && test "$_bitmap_font" = no && \
Index: mp_msg.c
===================================================================
--- mp_msg.c	(revision 29317)
+++ mp_msg.c	(working copy)
@@ -221,5 +221,6 @@
     header = tmp[strlen(tmp)-1] == '\n' || tmp[strlen(tmp)-1] == '\r';
 
     fprintf(stream, "%s", tmp);
+    fprintf(stream, "\033[m");
     fflush(stream);
 }
(note: you should remove -msse4.1)

and compile it like
[cmd=">"]./configure --enable-gui[/cmd] (though, I don't use GUI)
[cmd=">"]gmake -j3[/cmd]
Click to expand...

How did you use gcc45 without setting "./configure --cc=gcc45 --host-cc=gcc45 --enable-gui"? Did you just use make.conf? And how did you set up cross-binutils and how would I do this? Thanks
 
You must log in or register to reply here.
Back
Top