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



## DutchDaemon (May 19, 2009)

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.


----------



## richardpl (May 19, 2009)

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.


----------



## DutchDaemon (May 19, 2009)

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.


----------



## richardpl (May 19, 2009)

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.


----------



## DutchDaemon (May 19, 2009)

I. Was. Not. Asking. You. To. Help. Me.


----------



## tangram (May 19, 2009)

It's a wild shot but maybe this helps: http://www.freebsd.org/cgi/query-pr.cgi?pr=130966.


----------



## DutchDaemon (May 19, 2009)

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.


----------



## richardpl (May 19, 2009)

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 ....


----------



## hydra (May 19, 2009)

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


----------



## blah (May 19, 2009)

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'.


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.


----------



## DutchDaemon (May 19, 2009)

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.


----------



## hydra (May 19, 2009)

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.


----------



## blah (May 19, 2009)

*hydra*, I use gcc45 + binutils-2.19 (for SSSE3, from devel/cross-binutils) and these hacks
	
	



```
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]


----------



## hydra (May 19, 2009)

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.


----------



## blah (May 19, 2009)

*hydra*, if you're using old compiler/assembler from base you're likely bump into these while compiling libavcodec
	
	



```
{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.


----------



## hydra (May 20, 2009)

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.


----------



## DutchDaemon (May 22, 2009)

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.


----------



## morbit (Sep 18, 2009)

-O4? FFS!

Where do they get such ideas from?

http://gcc.gnu.org/viewcvs/trunk/gcc/opts.c?view=markup

*In case someone would blindly follow blah's patch*


----------



## SirDice (Sep 18, 2009)

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.


----------



## DutchDaemon (Sep 18, 2009)

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.


----------



## adamk (Sep 18, 2009)

It was an issue with OSS that, last time I checked, had been resolved:

http://4front-tech.com/forum/viewtopic.php?f=5&t=3024


----------



## DutchDaemon (Sep 18, 2009)

Thanks, I may give it another try, though FreeBSD 8's OSS layer works fine as it is.


----------



## DutchDaemon (Sep 19, 2009)

DutchDaemon said:
			
		

> Thanks, I may give it another try, though FreeBSD 8's OSS layer works fine as it is.



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 ..


----------



## SirDice (Sep 19, 2009)

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.



It seems to occur mainly when I skip though files. I'm on 7.2-STABLE.


----------



## ikbendeman (Feb 22, 2010)

blah said:
			
		

> *hydra*, I use gcc45 + binutils-2.19 (for SSSE3, from devel/cross-binutils) and these hacks
> 
> 
> 
> ...



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


----------



## morbit (Feb 22, 2010)

http://www.freebsd.org/doc/en/articles/custom-gcc/article.html


----------



## ikbendeman (Feb 23, 2010)

morbit said:
			
		

> http://www.freebsd.org/doc/en/articles/custom-gcc/article.html



this isn't in the ports collection, its the svn version, and thats for using binutils, not cross-binutils. that's why i asked if he used make.conf or --cc and --host-cc flags or make.conf... to use/build cross-binutils you need to define TGTARCH and TGTABI, I don't know how to do this.


----------



## morbit (Feb 25, 2010)

Why you think you should crossbuild If you only want to have gcc45 + new instructions I presume?

You can grab fresh mplayer (port) here also:

http://www.rrr.de/~riggs/mplayer/ *

It's private repo of current mplayer's port maintainer. 

TGTARCH etc. is environment variable.

eg. TGTARCH=x86_64 TGTABI=freebsd8


* http://docs.FreeBSD.org/cgi/mid.cgi?786602c61001301025n15e45702v6e6b7272eb59d3f8


----------



## ikbendeman (Feb 27, 2010)

morbit said:
			
		

> Why you think you should crossbuild If you only want to have gcc45 + new instructions I presume?
> 
> You can grab fresh mplayer (port) here also:
> 
> ...



because that is what was suggested in this thread... look at the patch that was posted. Is this a FreeBSD port? The reason I want to build from svn is the version in ports is way behind the current linux build. At least when I run smplayer it yells at me saying its a depricated version and to update or things won't work right... they do for the most part but there are some problems.


----------



## morbit (Feb 27, 2010)

If you would take time to read article I have posted, you'd know that crossbuilding was needed because there was no fresh binutils in ports tree. Patch has nothing to do with crossbuilding per se, it's generic amd64 (If I reckon correctly derived from patch in ports tree) quirk. Also, mplayer ports I have posted are quite fresh and have all needed patches.

EOT


----------



## initpy (Oct 27, 2012)

DutchDaemon said:
			
		

> 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.



Sorry to revive an old thread, but yes, I do experience the very same problem 
on my 9-stable with mplayer and OSS. Though I updated both from ports yesterday 
(make from sources)

I'd love to use snd_hda instead of OSS, but snd_hda refuses to give any sound on the internal speaker, so I'm restricted to OSS which crashes randomly when I skip (seek) in a video, and the whole system reboots.

So, DutchDaemon, did you find an explanation for this?


----------



## morbit (Oct 28, 2012)

How old is your 9-STABLE? I would update it and try to configure snd_hda properly (quirks).

In fact, I use snd_hda on (now) 9-STABLE since it was 8-CURRENT and I never had such problem with seeking.


----------



## initpy (Oct 28, 2012)

Thanks for the reply, morbit.

In fact, my 9-stable is not that old (9.1 pre-relase) and just to be sure, 
I also updated the files in /usr/src/sys/dev/sound/pci/hda/ with those 
in the svn repo as of today, and rebuilt the snd_hda module, but I still can't get the sound to come out of the internal speaker.

But that's another problem which I'm describing here: http://forums.freebsd.org/showthread.php?t=35383

The seeking and then crashing problem occurs only with mplayer + OSS and this is why I kind of revived this thread, but I'd by far prefer the snd_hda solution if it could output to the internal speaker

Thanks again!


----------

