After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 332503 - [oggdemux] crash when shut down right after start-up
[oggdemux] crash when shut down right after start-up
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.x
Other other
: High critical
: 0.10.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 337127 338546 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-02-25 00:09 UTC by Romain Chantereau
Modified: 2007-05-03 12:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Romain Chantereau 2006-02-25 00:09:25 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 ()

Thread 2 (Thread -1256072272 (LWP 9406))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 ogg_page_serialno
    from /usr/lib/libogg.so.0
  • #5 gst_task_get_type
    from /usr/lib/libgstreamer-0.10.so.0
  • #6 g_thread_pool_free
    from /usr/lib/libglib-2.0.so.0
  • #7 g_static_private_free
    from /usr/lib/libglib-2.0.so.0
  • #8 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #9 clone
    from /lib/tls/i686/cmov/libc.so.6




------- Bug created by bug-buddy at 2006-02-25 00:09 -------

Comment 1 Alex Lancaster 2006-02-25 08:51:35 UTC
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).
Comment 2 Alex Lancaster 2006-02-25 08:52:57 UTC
(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.
Comment 3 Jonathan Matthew 2006-02-26 00:25:02 UTC
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.
Comment 4 Karsten Bräckelmann 2006-04-04 02:31:37 UTC
*** Bug 337127 has been marked as a duplicate of this bug. ***
Comment 5 chris 2006-04-04 02:46:30 UTC
Here's some info after catching this red-handed in gdb:

Program received signal SIGSEGV, Segmentation fault.

Thread NaN (LWP 3946)

  • #0 ogg_page_serialno
    from /usr/lib/libogg.so.0
  • #1 gst_task_get_type
    from /usr/lib/libgstreamer-0.10.so.0
  • #2 g_thread_pool_free
    from /usr/lib/libglib-2.0.so.0
  • #3 g_static_private_free
    from /usr/lib/libglib-2.0.so.0
  • #4 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #5 clone
    from /lib/tls/i686/cmov/libc.so.6

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]
Comment 6 chris 2006-04-04 02:58:02 UTC
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

...

Thread 17 (Thread -1245111376 (LWP 4606))

  • #0 ogg_page_serialno
    from /usr/lib/libogg.so.0
  • #1 gst_task_get_type
    from /usr/lib/libgstreamer-0.10.so.0
  • #2 g_thread_pool_free
    from /usr/lib/libglib-2.0.so.0
  • #3 g_static_private_free
    from /usr/lib/libglib-2.0.so.0
  • #4 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #5 clone
    from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread -1245111376 (LWP 4606))

  • #0 ogg_page_serialno
    from /usr/lib/libogg.so.0
  • #1 gst_task_get_type
    from /usr/lib/libgstreamer-0.10.so.0
  • #2 g_thread_pool_free
    from /usr/lib/libglib-2.0.so.0
  • #3 g_static_private_free
    from /usr/lib/libglib-2.0.so.0
  • #4 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #5 clone
    from /lib/tls/i686/cmov/libc.so.6

Thread 4 (Thread -1245111376 (LWP 4606))

  • #0 ogg_page_serialno
    from /usr/lib/libogg.so.0
  • #1 gst_task_get_type
    from /usr/lib/libgstreamer-0.10.so.0
  • #2 g_thread_pool_free
    from /usr/lib/libglib-2.0.so.0
  • #3 g_static_private_free
    from /usr/lib/libglib-2.0.so.0
  • #4 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #5 clone
    from /lib/tls/i686/cmov/libc.so.6

Comment 7 Jonathan Matthew 2006-04-04 03:19:40 UTC
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.
Comment 8 Jonathan Matthew 2006-04-04 09:40:11 UTC
The only additional detail I can provide: 

  • #0 __kernel_vsyscall
  • #1 __lll_mutex_lock_wait
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 _L_mutex_lock_29
    from /lib/tls/i686/cmov/libpthread.so.0
  • #3 ??
  • #4 g_thread_equal_posix_impl
    at gthread-posix.c line 412
  • #5 g_static_rec_mutex_lock
    at gthread.c line 286
  • #6 gst_pad_stop_task
    at gstpad.c line 3963
  • #7 gst_ogg_demux_sink_activate_pull
    at gstoggdemux.c line 2688
  • #8 gst_pad_activate_pull
    at gstpad.c line 722
  • #9 gst_pad_set_active
    at gstpad.c line 649
  • #10 activate_pads
    at gstelement.c line 2254
  • #11 gst_iterator_fold
    at gstiterator.c line 503
  • #12 iterator_fold_with_resync
    at gstelement.c line 2272
  • #13 gst_element_pads_activate
    at gstelement.c line 2309
  • #14 gst_element_change_state_func
    at gstelement.c line 2370
  • #15 gst_ogg_demux_change_state
    at gstoggdemux.c line 2719
  • #16 gst_element_change_state
    at gstelement.c line 2177
  • #17 gst_element_set_state_func
    at gstelement.c line 2139
  • #18 gst_element_set_state
    at gstelement.c line 2049
  • #19 gst_bin_element_set_state
    at gstbin.c line 1753
  • #20 gst_bin_change_state_func
    at gstbin.c line 1825
  • #21 gst_decode_bin_change_state
    at gstdecodebin.c line 1427
  • #22 gst_element_change_state
    at gstelement.c line 2177
  • #23 gst_element_set_state_func
    at gstelement.c line 2139
  • #24 gst_element_set_state
    at gstelement.c line 2049
  • #25 gst_bin_element_set_state
    at gstbin.c line 1753
  • #26 gst_bin_change_state_func
    at gstbin.c line 1825
  • #27 gst_pipeline_change_state
    at gstpipeline.c line 485
  • #28 gst_play_base_bin_change_state
    at gstplaybasebin.c line 1794
  • #29 gst_play_bin_change_state
    at gstplaybin.c line 1382
  • #30 gst_element_change_state
    at gstelement.c line 2177
  • #31 gst_element_set_state_func
    at gstelement.c line 2139
  • #32 gst_element_set_state
    at gstelement.c line 2049
  • #33 rb_player_close
    at rb-player-gst.c line 831

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).
Comment 9 chris 2006-04-05 10:40:49 UTC
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?
Comment 10 James "Doc" Livingston 2006-04-12 13:35:38 UTC
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.
Comment 11 chris 2006-04-14 18:13:45 UTC
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.
Comment 12 James "Doc" Livingston 2006-04-15 00:14:45 UTC
*** Bug 338546 has been marked as a duplicate of this bug. ***
Comment 13 Bruno Santos 2006-05-10 03:48:57 UTC
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?
Comment 14 James "Doc" Livingston 2006-05-10 14:00:48 UTC
(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.
Comment 15 Nicolas da Luz Duque 2006-05-13 11:19:33 UTC
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

Thread 11 (Thread -1282364496 (LWP 23106))

  • #0 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #1 ??
  • #2 ??

Thread 7 (Thread -1282364496 (LWP 23106))

  • #0 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #1 ??
  • #2 ??

Thread 6 (Thread -1282364496 (LWP 23106))

  • #0 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #1 ??
  • #2 ??

Thread 5 (Thread -1282364496 (LWP 23106))

  • #0 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #1 ??
  • #2 ??

Thread 2 (Thread -1264800848 (LWP 23073))

  • #0 gst_push_src_get_type
    from /usr/lib/libgstbase-0.10.so.0
  • #1 gst_type_find_peek
    from /usr/lib/libgstreamer-0.10.so.0
  • #2 mpeg_ts_probe_headers
    from /usr/lib/gstreamer-0.10/libgsttypefindfunctions.so
  • #3 gst_type_find_factory_call_function
    from /usr/lib/libgstreamer-0.10.so.0
  • #4 gst_type_find_helper_get_range
    from /usr/lib/libgstbase-0.10.so.0
  • #5 gst_id3demux_get_type
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #6 gst_pad_set_active
    from /usr/lib/libgstreamer-0.10.so.0
  • #7 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #8 gst_iterator_fold
    from /usr/lib/libgstreamer-0.10.so.0
  • #9 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #10 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #11 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #12 gst_id3demux_get_type
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #13 gst_element_continue_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #14 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #15 gst_element_set_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #16 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #17 ??
  • #18 ??
  • #19 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #20 ??
  • #21 ??

Comment 16 James "Doc" Livingston 2006-06-07 13:58:49 UTC
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.
Comment 17 Jonathan Matthew 2006-06-07 22:31:44 UTC
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.
Comment 18 Wim Taymans 2007-01-27 13:33:19 UTC
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.
Comment 19 Tim-Philipp Müller 2007-05-03 12:31:02 UTC
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).