Red Hat Bugzilla – Bug 163492
XMMS crashes (no hanging) on add directory if contains a filename is without .mp3 extension
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Description of problem:
XMMS crashes instantly (no hanging) if add directory to populate playlist is chooen if and only if one of the file in directory (tree) being added does not have .mp3 extension on filename.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.open xmms clear playlist (or haveit as it is)
2.add directory to playlist. navigate to the desired direcory. (directory must have at least one mp3 file named without .mp3 extension
3. press ok to accept the directory and it crashes.
Actual Results: XMMS crashes system and other application keeps working normal.
Expected Results: playlist should be renewed with additional songs to be selected for play or further funactions.
UI = kde
motherboard Intel D865GBF with onboard 5.1 channel audio.
5.1 channel drives (speakers set)
Actual Results: XMMS crashes. whereas system and other application keeps
xmms is in extras now. Assigning there.
Cannot reproduce if following the "Steps to reproduce".
(In reply to comment #3)
> Cannot reproduce if following the "Steps to reproduce".
Thanks for confirming.
Is there any check I may do at my end? Thanks.
You could provide a backtrace of when the crash occurs:
You could query your RPM database: rpm -qa 'xmms*'
You could try to reduce your files to a reproducible test-case, so it can be
examined whether file names or content cause the crash. Might be a buffer
overflow in a plugin, triggered by a specific mp3 file in your directory.
(In reply to comment #5)
Please bear with replies after 18-24 hours - timezone between us.
> You could provide a backtrace of when the crash occurs:
Will include a proper stacktrace as guided in wiki article.
> You could query your RPM database: rpm -qa 'xmms*'
This I will attach with backtrace post.
> You could try to reduce your files to a reproducible test-case, so it can be
> examined whether file names or content cause the crash. Might be a buffer
> overflow in a plugin, triggered by a specific mp3 file in your directory.
This is already tested in three stages
1). big tree of 12 sub-dir and 147 files
2). one directory of 12 files
3). single file (faulty one)
Same result. Workaround is simply to rename the file with .mp3 extension then
it works in all 3 cases above. In fact I test loaded full collection of 3000+
files - It works. Crash was noted only when this typical file (on CD/hdd) was
added to playlist.
Please wait for submission of backtrace from me.
First I have to fix another broken application - my car's hydraulics sytem for
power steering. This is not as free as fedora but equally good. Also very
limited help available in this case.
- just the lighter side.
Reassigning to the current maintainer (Ville).
I can't reproduce either, and since it's been almost a year without additional
feedback, closing. If you can still reproduce in FC5+, feel free to reopen and
include the info requested in comment 5.