GNOME Bugzilla – Bug 395717
Gnome sound recorder crashes when clicked to play files, if G_DEBUG is set to fatal_criticals
Last modified: 2007-01-18 02:44:19 UTC
Steps to reproduce: set G_DEBUG=fatal_criticals 1. Start gnome-sound-recorder 2. click open to open a music file 3. click play button to play Stack trace: gnome-sound-recorder ----------------- lwp# 1 / thread# 1 -------------------- d0f688f5 pollsys (836a370, b, 0, 0) d0f1f7b2 poll (836a370, b, ffffffff) + 52 d0cb4aeb g_main_context_iterate (80e24c8, 1, 1, 8076858) + 397 d0cb5124 g_main_loop_run (8322358) + 1b8 d059a2ba gtk_main (8047abc, 80479f4, d0ffb7c0, d0ffb7c0, 0, 8061e4c) + b2 08058cc5 main (1, 8047a38, 8047a40) + 1d1 0805883a _start (1, 8047b24, 0, 8047b39, 8047b6d, 8047b7f) + 7a ----------------- lwp# 2 / thread# 2 -------------------- d0f678b9 lwp_park (0, 0, 1) d0f61ad2 cond_wait_queue (82e51b8, 82e5f98, 0, 0) + 3e d0f61fbd _cond_wait (82e51b8, 82e5f98) + 69 d0f61ffb cond_wait (82e51b8, 82e5f98) + 24 d0f62035 pthread_cond_wait (82e51b8, 82e5f98) + 1e d0e5e9e2 gst_system_clock_async_thread (82baac0) + 19e d0cce676 g_thread_create_proxy (82f3d88) + 11a d0f67604 _thr_setup (d0952400) + 52 d0f67860 _lwp_start (d0952400, 0, 0, 0, 0, 0) ----------------- lwp# 7 / thread# 7 -------------------- d0f688f5 pollsys (cc9acb70, 1, 0, 0) d0f23fce pselect (5, cc9acc40, d0fa2278, d0fa2278, 0, 0) + 19e d0f242de select (5, cc9acc40, 0, 0, 0) + 7e cdf808b1 _XWaitForReadable (8092848) + cd cdf806da _XRead (8092848, cc9acd70, 20) + a6 cdf81305 _XReply (8092848, cc9acd70, 0, 1) + cd cdf88a0c XSync (8092848, 0) + 68 cdfad6dd _XSyncFunction (8092848) + 1d cdf95a3a XUngrabServer (8092848) + 82 d08f8275 libgnomeui_segv_handle (6, 0, cc9acef0) + 95 d0f6795f __sighndlr (6, 0, cc9acef0, d08f81e0) + f d0f5cfbb call_use78, 8163058) + 98 d0e7b56a gst_marshal_VOID__OBJECT_PARAM (80b2140, 0, 3, cc9ad7fc, cc9ad75c, 0) + 5e d0d3e073 g_closure_invoke (80b2140, 0, 3, cc9ad7fc, cc9ad75c) + 107 d0d51cce signal_emit_unlocked_R (808af48, 5fa, 849c008, 0, cc9ad7fc) + 746 d0d50fe0 g_signal_emit_valist (849c008, c, 5fa, cc9ada74) + 8c4 d0d51175 g_signal_emit (849c008, c, 5fa, 84a20f8, 814f678) + 25 d0e26538 gst_object_dispatch_properties_changed (84a20f8, 1, cc9adb00) + 154 d0d3f43b g_object_notify_dispatcher (84a20f8, 1, cc9adb00) + 17 d0d3f1fd g_object_notify_queue_thaw (84a20f8, 80cdd70) + c9 d0d403e7 g_object_notify (84a20f8, d0e96070) + 17f d0e4c57a gst_pad_set_caps (84a20f8, 8334ac0) + 262 d0e4c739 gst_pad_configure_src (84a20f8, 8334ac0, 1) + 81 d0e4e99c gst_pad_push (84a20f8, 8357820) + 1b4 cc891286 gst_stream_selector_chain (84a2338, 8357820) + 19e d0e4e40f gst_pad_chain_unchecked (84a2338, 8357820) + 1c7 d0e4ea1b gst_pad_push (82d9620, 8357820) + 233 d0e3eba5 gst_proxy_pad_do_chain (82d7e50, 8357820) + 25 d0e4e0cce676 g_thread_create_proxy (8499d90) + 11a d0f67604 _thr_setup (cc9b0400) + 52 d0f67860 _lwp_start (cc9b0400, 0, 0, 0, 0, 0) ----------------- lwp# 8 / thread# 8 -------------------- d0f678b9 lwp_park (0, 0, 7) d0f61ad2 cond_wait_queue (84bc300, 80c63b0, 0, 0) + 3e d0f61fbd _cond_wait (84bc300, 80c63b0) + 69 d0f61ffb cond_wait (84bc300, 80c63b0) + 24 d0f62035 pthread_cond_wait (84bc300, 80c63b0) + 1e d0e5e9e2 gst_system_clock_async_thread (830c240) + 19e d0cce676 g_thread_create_proxy (84ba9d8) + 11a d0f67604 _thr_setup (cc9b0000) + 52 d0f67860 _lwp_start (cc9b0000, 0, 0, 0, 0, 0) ----------------- lwp# 9 / thread# 9 -------------------- d0f678b9 lwp_park (0, 0, 0) d0f61ad2 cond_wait_queue (83519f0, 80c8dd0, 0, 0) + 3e d0f61fbd _cond_wait (83519f0, 80c8dd0) + 69 d0f61ffb cond_wait (83519f0, 80c8dd0) + 24 d0f62035 pthread_cond_wait (83519f0, 80c8dd0) + 1e cd3e82d2 gst_queue_loop (84a2278) + 462 d0e644b3 gst_task_func (8357960, 8499cc0) + 1cf d0ccfad7 g_thread_pool_thread_proxy (8499d58) + b3 d0cce676 g_thread_create_proxy (84baad0) + 11a d0f67604 _thr_setup (cc9b0800) + 52 d0f67860 _lwp_start (cc9b0800, 0, 0, 0, 0, 0) Other information:
Could you send me the commandline output also so I know wich one is failing? Right now, I don't know which call in the notify callback is failing. The only one that could posibly fail is gst_caps_get_structure (caps, 0), but really, for any audio element, that should never happen...
Created attachment 80305 [details] command line output when GST_DEBUG is set to 3 hi, Ronald, the attached is the commandline output you are after :). Hope it may give you some idea. The critical warnings happens on Solaris and Ubuntu (I don't know about the other OS, since I don't have them). But it does not happen on Suse, with gnome 2.14.
So gst_element_get_factory() returns a non-NULL alue, but it is not a GstElementFactory. Very odd... I can't reproduce this on Ubuntu Dapper, btw, I'm assuming you've tested on Ubuntu Edgy?
I've tested it on Ubuntu 6.10.
Created attachment 80486 [details] [review] patch Hi, Ronald Here's the patch that we worked out. And we don't know why the factory of element with the name "selector_audio_src0" is NULL.
Oh, I didn't realize that code didn't exist yet in older versions. In newer versions, that's already fixed: http://svn.gnome.org/viewcvs/gnome-media/trunk/grecord/src/gsr-window.c?rev=3454&r1=3447&r2=3454 It's probably a good idea to test such bugs/crashers with more recent versions, particularly since you're an active contributer to a distro package. that way, if you find that newer versions work, I can just scan the changelog and point you to the relevant patch. :-). *** This bug has been marked as a duplicate of 352135 ***
Thanks Ronald, This patch sure works :). Actually, it is logically the same as the patch we've worked out. Thanks again.