FS#22971 - [moc] Crashes while switching song when using OSS

Attached to Project: Arch Linux
Opened by Stefan Schick (pommes_) - Saturday, 19 February 2011, 22:12 GMT
Last edited by Eric Belanger (Snowman) - Friday, 10 June 2011, 23:04 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When I use OSS moc crashes when switching from now ending Song to the next.

Version: 2.4.4-3, also happens with Version moc-devel-2.5.0-3 from AUR.


relevant part of ~/.moc/config
# Sound driver - OSS, ALSA, JACK, or null (only for debugging)
# You can enter more than one driver separated by a coma. The first working
# driver will be used.
SoundDriver = OSS, ALSA
# Jack output settings
#JackOutLeft = "alsa_pcm:playback_1"
#JackOutRight = "alsa_pcm:playback_2"

# OSS output device
#OSSDevice = /dev/dsp28
OSSDevice = /dev/dsp1

# OSS Mixer device
#OSSMixerDevice = /dev/mixer
#OSSMixerDevice = /dev/dsp1

# OSS Mixer channel: pcm or master
#OSSMixerChannel = pcm

# Second OSS Mixer channel: pcm or master
#OSSMixerChannel2 = master


Backtrace:
Program terminated with signal 6, Aborted.
#0 0x00007ffff68ee655 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff68ee655 in raise () from /lib/libc.so.6
#1 0x00007ffff68efad6 in abort () from /lib/libc.so.6
#2 0x00007ffff68e7285 in __assert_fail () from /lib/libc.so.6
#3 0x000000000041450f in out_buf_time_get (buf=0x657ac0) at out_buf.c:347
#4 0x000000000042c52b in update_time () at player.c:218
#5 buf_free_callback () at player.c:416
#6 0x00000000004139f7 in read_thread (arg=0x657ac0) at out_buf.c:91
#7 0x00007ffff6c23cb0 in start_thread () from /lib/libpthread.so.0
#8 0x00007ffff698f95d in clone () from /lib/libc.so.6
#9 0x0000000000000000 in ?? ()


Steps to reproduce:
- configure moc to use OSS
- start moc and play a song
- wait til song ends
This task depends upon

Closed by  Eric Belanger (Snowman)
Friday, 10 June 2011, 23:04 GMT
Reason for closing:  Fixed
Additional comments about closing:  moc 20110528-2
Comment by Thomas Dziedzic (tomd123) - Saturday, 26 February 2011, 17:30 GMT
did you try moc-svn?
Comment by Stefan Schick (pommes_) - Sunday, 27 February 2011, 09:50 GMT
It seems to be fixed in moc-svn. I think it would be a good idea to update the package in extra.
Comment by Eric Belanger (Snowman) - Thursday, 19 May 2011, 03:39 GMT
I can't reproduce it. Do you still have that problem?
Comment by Stefan Schick (pommes_) - Thursday, 19 May 2011, 09:06 GMT
The problem persists with moc-2.4.4-4.
Comment by Eric Belanger (Snowman) - Thursday, 19 May 2011, 22:15 GMT
Is your system up-to-date? Are you using testing repo?
Could you try moc-2.5.0-alpha4 to see if it's fixed in that version? It might help me coming up with a patch.
Comment by Eric Belanger (Snowman) - Thursday, 19 May 2011, 22:43 GMT
I just saw in your bug report that you already tried moc-2.5.0-alpha4. I'll check what changed in the svn since these versions.
Comment by Eric Belanger (Snowman) - Sunday, 29 May 2011, 06:18 GMT
Could you test the package there: https://dev.archlinux.org/~eric/moc/ and let me know if they fix the problem? They use a svn snapshot which is used by Debian.
Comment by Stefan Schick (pommes_) - Monday, 30 May 2011, 16:33 GMT
It didn't fix it.
Comment by Eric Belanger (Snowman) - Monday, 30 May 2011, 20:59 GMT
I've put moc-20110528-1 in testing. It uses a snapshot from the current code in svn so it should work.
Comment by Stefan Schick (pommes_) - Wednesday, 01 June 2011, 16:30 GMT
I'm sorry, I didn't want to believe it, but moc-20110528-1 in testing has the same issue. I tested it in every way I could imagine, but the only version that works is the moc-svn from AUR, but I don't understand why. Maybe they used some other compile flags or whatever.
Comment by Thomas Dziedzic (tomd123) - Wednesday, 01 June 2011, 17:35 GMT
The only difference between moc and moc-svn is that I use libtoolize -f and in the configure --disable-debug and I also do export CPPFLAGS="$CPPFLAGS -I/usr/lib/oss/include", besides that, the PKGBUILDs look identical

The sed & patch commands in the testing/moc/PKGBUILD file probably shouldn't be there since it's a snapshot of svn
Comment by Thomas Dziedzic (tomd123) - Wednesday, 01 June 2011, 17:41 GMT
Actually, I got rid of libtoolize -f from moc-svn since ./autogen.sh already does this
Comment by Eric Belanger (Snowman) - Wednesday, 01 June 2011, 17:52 GMT
I don't have a /usr/lib/oss/include directory on my system. Do you build moc-svn in a chroot? If not, do you have oss (or a package that installs files in /usr/lib/oss/include) on your system?
Comment by Thomas Dziedzic (tomd123) - Wednesday, 01 June 2011, 18:02 GMT
the package "oss" installs files to that directory

I don't build it in a chroot nor do I use oss/have it on my system, so I have never had a problem with this.

That include is a left over from the previous packager, and I haven't checked if it is still necessary.
Comment by Eric Belanger (Snowman) - Saturday, 04 June 2011, 23:11 GMT
FTR, the patch is still needed to fix  FS#23879 . I get that bug with moc-svn without that patch. Is it the same for you? The sed lines are no longer needed indeed.

Could you test the following packages and tell me if they work?
http://dev.archlinux.org/~eric/moc/moc-svn-2330-1-x86_64.pkg.tar.xz
http://dev.archlinux.org/~eric/moc/moc-2330-1-x86_64.pkg.tar.xz

The first one is just the moc-svn package from AUR except the sidplay2 support that was added recently. It'll tell us if the bug is caused in how I build the package (e.g. in a chroot). The second one use the same svn checkout than moc-svn but with the PKGBUILD I used for the package in testing. That'll help me to pinpoint what's causing the bug.
Comment by Stefan Schick (pommes_) - Sunday, 05 June 2011, 08:47 GMT
moc-svn-2330-1-x86_64.pkg.tar.xz works fine
moc-2330-1-x86_64.pkg.tar.xz doesn't work
Comment by Eric Belanger (Snowman) - Monday, 06 June 2011, 02:56 GMT
In that case, the problem is caused by: the patch, the missing CPPFLAGS line or the --disable-debug configure option (not likely).
Try these:
http://dev.archlinux.org/~eric/moc/moc-nopatch-2330-1-x86_64.pkg.tar.xz
http://dev.archlinux.org/~eric/moc/moc-cppflags-2330-1-x86_64.pkg.tar.xz
Comment by Stefan Schick (pommes_) - Monday, 06 June 2011, 15:47 GMT
None of them works, so it has to be the debug flag. But why and how can that be?
Comment by Eric Belanger (Snowman) - Monday, 06 June 2011, 21:02 GMT
I supposes that there is a bug in the debug code. Your system or your files have an issue of some sort and the debug code tries to do something, like print a message, and it crashes the app. I don't have that issue on my system so the debug code isn't used. That would explain why I can't reproduce it. Luckily, the moc-svn in AUR had that option otherwise we might have been able to find the problem. Anyway, could you test this just to be sure:
http://dev.archlinux.org/~eric/moc/moc-nodebug-2330-1-x86_64.pkg.tar.xz

Comment by Thomas Dziedzic (tomd123) - Monday, 06 June 2011, 21:19 GMT
could someone please post this issue upstream so it can get fixed properly?
Comment by Stefan Schick (pommes_) - Tuesday, 07 June 2011, 21:17 GMT
moc-nodebug-2330-1-x86_64.pkg.tar.xz works fine.
Comment by Eric Belanger (Snowman) - Wednesday, 08 June 2011, 05:55 GMT
Upstream developement is pretty much dead IMO. The latest releases are several years old. There are commits in svn but it looks more like patches submitted by users and distros. Stefan: if you want to submit a bug report upstream, build moc with --enable-debug
and run mocp in debug mode (with the -D switch). That will create logs that you'll want to submit with the bug report.

Another, hopefully last, test:
http://dev.archlinux.org/~eric/moc/moc-20110528-2-x86_64.pkg.tar.xz

If you confirm that it works, it'll go in testing and you'll be done doing these tests. It's basically the current testing package with debug disabled and the sed lines removed. The svn snapshot is a few days older than the 2330 versions that you tested earlier. I don't think it matters but I don't want to take any chances. ;)

Comment by Stefan Schick (pommes_) - Wednesday, 08 June 2011, 11:49 GMT
You can put it into Testing, it works fine. I am going to report it upstream in the next days.

Thank you Eric for your time and patience!

Loading...