GNOME Bugzilla – Bug 332503
[oggdemux] crash when shut down right after start-up
Last modified: 2007-05-03 12:31:02 UTC
Distribution: Debian testing/unstable Package: rhythmbox Severity: critical Version: GNOME2.12.2 0.9.3 Gnome-Distributor: Debian Synopsis: Crash when I start the program Bugzilla-Product: rhythmbox Bugzilla-Component: General Bugzilla-Version: 0.9.3 BugBuddy-GnomeVersion: 2.0 (2.12.1) Description: Description of the crash: I specified a directory where my music are (around 100 Go). and it load, load, and crash. Steps to reproduce the crash: 1. 2. 3. Expected Results: How often does this happen? everytime Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/rhythmbox' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1226787136 (LWP 9063)] [New Thread -1256072272 (LWP 9406)] [New Thread -1271923792 (LWP 9082)] [New Thread -1268278352 (LWP 9081)] [New Thread -1268012112 (LWP 9080)] [New Thread -1267745872 (LWP 9079)] [New Thread -1267479632 (LWP 9074)] [New Thread -1267213392 (LWP 9073)] [New Thread -1266947152 (LWP 9072)] [New Thread -1266680912 (LWP 9071)] [New Thread -1265251408 (LWP 9070)] [New Thread -1264985168 (LWP 9069)] [New Thread -1246778448 (LWP 9065)] [New Thread -1238385744 (LWP 9064)] (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 66493
Thread 2 (Thread -1256072272 (LWP 9406))
------- Bug created by bug-buddy at 2006-02-25 00:09 -------
This could be related to a specific file in your library. Can you try starting it up with an empty library, and then add back directories in stages to try and find out which file or files might be causing it? Because it's a large library it might also be related to bug #331876 (I sometimes get a hang when attempting load large libraries because of the interaction between gnome-vfs and gam_server).
(In reply to comment #1) > This could be related to a specific file in your library. Can you try starting > it up with an empty library, and then add back directories in stages to try and > find out which file or files might be causing it? i.e. don't load the entire music directory in one hit, just import files and/or subdirectories in stages.
Or, if you can catch the crash in gdb, run 'ls -l /proc/`pidof rhythmbox`/fd/' to see what files it has open when it crashes.
*** Bug 337127 has been marked as a duplicate of this bug. ***
Here's some info after catching this red-handed in gdb: Program received signal SIGSEGV, Segmentation fault.
+ Trace 67433
Thread NaN (LWP 3946)
The info from /proc isn't too interesting; rhythmbox does not appear to have any open files. Though perhaps that's the source of the problem :) chris@rs6:~$ ls -l /proc/`pidof rhythmbox`/fd/ total 29 lrwx------ 1 chris chris 64 2006-04-03 22:43 0 -> /dev/pts/0 lrwx------ 1 chris chris 64 2006-04-03 22:43 1 -> /dev/pts/0 l-wx------ 1 chris chris 64 2006-04-03 22:43 10 -> pipe:[1877423] lr-x------ 1 chris chris 64 2006-04-03 22:43 11 -> pipe:[1877424] l-wx------ 1 chris chris 64 2006-04-03 22:43 12 -> pipe:[1877424] lrwx------ 1 chris chris 64 2006-04-03 22:43 13 -> socket:[1877431] lrwx------ 1 chris chris 64 2006-04-03 22:43 14 -> socket:[1877433] lrwx------ 1 chris chris 64 2006-04-03 22:43 15 -> socket:[1877436] lr-x------ 1 chris chris 64 2006-04-03 22:43 16 -> /proc/cpuinfo lrwx------ 1 chris chris 64 2006-04-03 22:43 17 -> socket:[1877531] lrwx------ 1 chris chris 64 2006-04-03 22:43 18 -> socket:[1877546] lrwx------ 1 chris chris 64 2006-04-03 22:43 19 -> socket:[1877543] lrwx------ 1 chris chris 64 2006-04-03 22:43 2 -> /dev/pts/0 lrwx------ 1 chris chris 64 2006-04-03 22:43 20 -> socket:[1877547] lr-x------ 1 chris chris 64 2006-04-03 22:43 21 -> pipe:[1877551] l-wx------ 1 chris chris 64 2006-04-03 22:43 22 -> pipe:[1877551] lr-x------ 1 chris chris 64 2006-04-03 22:43 23 -> pipe:[1877552] l-wx------ 1 chris chris 64 2006-04-03 22:43 24 -> pipe:[1877552] lrwx------ 1 chris chris 64 2006-04-03 22:43 25 -> socket:[1877591] lrwx------ 1 chris chris 64 2006-04-03 22:43 26 -> socket:[1877594] lrwx------ 1 chris chris 64 2006-04-03 22:43 27 -> socket:[1877651] lrwx------ 1 chris chris 64 2006-04-03 22:43 28 -> socket:[1877617] lr-x------ 1 chris chris 64 2006-04-03 22:43 3 -> pipe:[1877378] l-wx------ 1 chris chris 64 2006-04-03 22:43 4 -> pipe:[1877378] lr-x------ 1 chris chris 64 2006-04-03 22:43 5 -> /usr/bin/rhythmbox lrwx------ 1 chris chris 64 2006-04-03 22:43 6 -> socket:[1877529] lr-x------ 1 chris chris 64 2006-04-03 22:43 7 -> pipe:[1877422] l-wx------ 1 chris chris 64 2006-04-03 22:43 8 -> pipe:[1877422] lr-x------ 1 chris chris 64 2006-04-03 22:43 9 -> pipe:[1877423]
I don't know if this reveals anything other than a gdb and/or pthread_db bug, but the faulting thread is duplicated three times: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1245111376 (LWP 4606)] 0xb6b89459 in ogg_page_serialno () from /usr/lib/libogg.so.0 (gdb) thread [Current thread is 17 (Thread -1245111376 (LWP 4606))] (gdb) thread apply all bt ...
+ Trace 67434
Thread 17 (Thread -1245111376 (LWP 4606))
Thread 6 (Thread -1245111376 (LWP 4606))
Thread 4 (Thread -1245111376 (LWP 4606))
It looks like this is happening while the pipeline is shutting down. The source element has already been destroyed, so the file is closed. I guess you'll need to run rhythmbox with the -d option to find out which file is being read when it crashes, but I suspect this information won't actually be useful. I've seen a similar crash when starting playback and hitting 'next' while the library is still loading. It doesn't seem to matter which file is played, as long as it's in ogg vorbis format. I'll try to get a stack trace with full debug info.
The only additional detail I can provide:
+ Trace 67436
I can't seem to get any detail on the oggdemux task thread. There's obviously something between gst_task_func() and ogg_page_serialno(), but gdb refuses to tell me what. I'm using gstreamer core and -base from CVS very-nearly-HEAD (maybe a day or two old).
I think I may have found something useful. I used strace to watch which files rhythmbox opened prior to crashing and was able to narrow the problem down to a specific directory in my library with several OGG files. I ran ogginfo on the files in the directory and it warned about a stream with serial number zero in each: chris@rs6:~/audio/thomas/songs$ ogginfo DonaldsDuck.ogg Processing file "DonaldsDuck.ogg"... Note: Stream 1 has serial number 0, which is legal but may cause problems with some tools. New logical stream (#1, serial: 00000000): type FLAC Logical stream 1 ended Perhaps the gstreamer OGG code can't deal with this?
Can you try playing one of those tracks with totem-gstreamer or "gst-launch playbin uri=file:///path/to/file.ogg"? It it doesn't work with those then it will be a gstreamer issue.
I tried the following: gst-launch-0.8 playbin uri=file:///path/to/file.ogg and everything worked just fine, though I'm somewhat suspicious about whether or not this used the same version of gstreamer that's underneath rythmbox. The system is running Debian testing, and appears to have both gstreamer-0.8 and gstreamer-0.10 components installed. I'll do a little more digging to see if I can clarify the situation.
*** Bug 338546 has been marked as a duplicate of this bug. ***
It seems rb tries to load even non media files, when a folder is imported, is this normal? Could it be that 'feeding' non media files to gst makes it crash? The import errors go from decode plugin not found to internal error, what should be done? Should I issue another bug report? Is this normal behaviour?
(In reply to comment #13) > It seems rb tries to load even non media files, when a folder is imported, is > this normal? Yes, because until rb tries to import them it doesn't know whether they are media files or not. > Could it be that 'feeding' non media files to gst makes it crash? Certainly, and there have been *lots* of bugs reported where GStreamer was crashing on something. RB 0.9.4 supports an "out-of-process metadata loader" which makes GStreamer crashing not take down Rhyhmbox, but the reporter had 0.9.3. > The import errors go from decode plugin not found to internal error, what > should be done? Should I issue another bug report? Is this normal behaviour? I'm not exactly sure what you mean.
I think I'm encountering the same problem. I'm using rhythmbox version 0.9.3.1 on an ubuntu dapper updated daily. The file produced by "rhythmbox -d 2> rb_crash.log" is available here: http://membres.lycos.fr/ekillersclan/Trucs_en_vrac/rb_crash.log And here's the stack trace obtained via gdb: (gdb) thread apply all bt
+ Trace 68197
Thread 11 (Thread -1282364496 (LWP 23106))
Thread 7 (Thread -1282364496 (LWP 23106))
Thread 6 (Thread -1282364496 (LWP 23106))
Thread 5 (Thread -1282364496 (LWP 23106))
Thread 2 (Thread -1264800848 (LWP 23073))
I've split Nicolas' issue off into a separate bug, since it's an unrelated issue. This looks like a gstreamer issue, so moving there. Comments 8 has the useful stack trace.
At the time I was investigating this, I found that the crash only occurred when shutting down the pipeline before it had output anything, and that recompiling oggdemux with -O0 either fixed the problem or hid it to the point where I could no longer reproduce it.
Does this patch to CVS change anything? * ext/ogg/gstoggdemux.c: (gst_ogg_demux_submit_buffer), (gst_ogg_demux_get_data), (gst_ogg_demux_get_next_page), (gst_ogg_demux_get_prev_page), (gst_ogg_demux_do_seek), (gst_ogg_demux_perform_seek), (gst_ogg_demux_bisect_forward_serialno), (gst_ogg_demux_read_chain), (gst_ogg_demux_read_end_chain), (gst_ogg_demux_find_chains), (gst_ogg_demux_handle_page), (gst_ogg_demux_chain), (gst_ogg_demux_combine_flows), (gst_ogg_demux_loop_reverse), (gst_ogg_demux_loop): * ext/ogg/gstoggdemux.h: Properly propagate streaming errors when we are scanning the file for chains so that we don't crash when shut down. Might fix some crashers when quickly switching oggs in RB such as #332503 and #378436.
I'm fairly sure this is fixed. Please re-open if this is still a problem with gst-plugins-base 0.10.12 (ie. what's in Ubuntu Feisty).