Red Hat Bugzilla – Bug 660507
[abrt] audacious-2.4.0-3.fc14.1: xmp_smix_softmixer: Process /usr/bin/audacious2 was killed by signal 11 (SIGSEGV)
Last modified: 2010-12-11 19:03:54 EST
abrt version: 1.1.14
Attached file: backtrace
reason: Process /usr/bin/audacious2 was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
How to reproduce
An ancient MOD file crashes the XMP plugin for Audacious whereas "xmp" cli rejects the file.
Note that the file is valid, but since it is very complicated to safely detect the specific MOD format it uses, most multi-format MOD players either fail at playing it correctly when using automated format detection.
Created attachment 465101 [details]
Created attachment 465103 [details]
an ancient MOD file
On F-13, this update works for me: https://admin.fedoraproject.org/updates/xmp-3.3.0-1.fc13 ? Could you try the corresponding F-14 update https://admin.fedoraproject.org/updates/xmp-3.3.0-1.fc14?
What modfile format is it? I'm sure upstream will be interested anyway (I'm sending the sample), but any additional information will be welcome.
And by "works for me" I meant it doesn't crash.
Oh, thought ABRT would have handled that. :) This is specifically about
$ rpm -q audacious-plugin-xmp audacious
and downgrading the xmp plugin doesn't help. So, it's not regression caused by the test update. F13 is an older Audacious. Will need to try.
The file format is Soundtracker older than 2.3, but not Ultimate Soundtracker compatible. Detecting it 100% is non-trivial, but that's not the reason for this ticket. A player/plugin should not crash and trigger ABRT as such mod files are still out in the wild.
Angie_S.mod: Format: Soundtracker 4 channels/15 samples
Effects: 0 1 2 12 15
Effect 0: 1 times
Effect 1: 16 times
Effect 2: 51 times
Effect 12: 311 times
Effect 15: 25 times
High portamento up >0x1f: 1 times.
High portamento down >0x1f: 1 times.
Samples: wlen (blen) repoff repwlen (repend)
12c0 (2580) 0000 0001 (0002)
0d16 (1a2c) 0000 0001 (0002)
0b73 (16e6) 0082 0aee (16e0) *byte-loop in range*
0c1d (183a) 0082 0aee (16e0) *byte-loop in range*
0cdc (19b8) 0082 0aee (16e0) *byte-loop in range*
0b54 (16a8) 0000 0001 (0002)
09b0 (1360) 0000 0001 (0002)
1068 (20d0) 0000 0001 (0002)
0c4c (1898) 0000 0001 (0002)
08fc (11f8) 0000 0001 (0002)
1036 (206c) 0000 0001 (0002)
1356 (26ac) 0000 0001 (0002)
1309 (2612) 0000 0001 (0002)
05dc (0bb8) 0000 0001 (0002)
06d6 (0dac) 0000 0001 (0002)
New test-case for F14:
1. start Audacious
2. disable ModPlug plugin
3. clear playlist
4. add file Angie_S.mod to playlist
4.2. file isn't detected (length 0:00) but added
5. add any other accepted MOD file to playlist
6. start playback with Angie_S.mod
What happens is that the file _is rejected_ just as with "xmp" cli, but when the playlist position jumps to the next track, the XMP plugin crashes.
Could you try this build? http://koji.fedoraproject.org/koji/buildinfo?buildID=208572
The fix works!
xmp-3.3.0-2.fc14 has been submitted as an update for Fedora 14.
xmp-3.3.0-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update xmp'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xmp-3.3.0-2.fc14
xmp-3.3.0-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.