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 386847 - crash in Volume Control: Surfing the net - visiti...
crash in Volume Control: Surfing the net - visiti...
Status: RESOLVED DUPLICATE of bug 391278
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other All
: High critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 362311 379379 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-12-17 17:12 UTC by rvbhute
Modified: 2007-01-08 22:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description rvbhute 2006-12-17 17:12:29 UTC
What were you doing when the application crashed?
Surfing the net - visiting Orkut


Distribution: Ubuntu 6.10 (edgy)
Gnome Release: 2.16.1 2006-10-02 (Ubuntu)
BugBuddy Version: 2.16.0

Memory status: size: 34680832 vsize: 0 resident: 34680832 share: 0 rss: 4870144 rss_rlim: 0
CPU usage: start_time: 1166375524 rtime: 0 utime: 0 stime: 0 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0

Backtrace was generated from '/usr/libexec/mixer_applet2'

(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 -1226052848 (LWP 7274)]
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()

Thread 1 (Thread -1226052848 (LWP 7274))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 gnome_gtk_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 g_slice_alloc
    from /usr/lib/libglib-2.0.so.0
  • #5 g_slice_alloc0
    from /usr/lib/libglib-2.0.so.0
  • #6 g_type_create_instance
    from /usr/lib/libgobject-2.0.so.0
  • #7 g_object_set
    from /usr/lib/libgobject-2.0.so.0
  • #8 g_object_newv
    from /usr/lib/libgobject-2.0.so.0
  • #9 g_object_new_valist
    from /usr/lib/libgobject-2.0.so.0
  • #10 g_object_new
    from /usr/lib/libgobject-2.0.so.0
  • #11 gst_registry_xml_write_cache
    from /usr/lib/libgstreamer-0.10.so.0
  • #12 gst_registry_xml_read_cache
    from /usr/lib/libgstreamer-0.10.so.0
  • #13 gst_init
    from /usr/lib/libgstreamer-0.10.so.0
  • #14 gst_init
    from /usr/lib/libgstreamer-0.10.so.0
  • #15 g_option_context_parse
    from /usr/lib/libglib-2.0.so.0
  • #16 gst_init_check
    from /usr/lib/libgstreamer-0.10.so.0
  • #17 gst_init
    from /usr/lib/libgstreamer-0.10.so.0
  • #18 main
  • #0 __kernel_vsyscall

Comment 1 palfrey 2006-12-17 20:51:24 UTC
Thanks for taking the time to report this bug.
Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 rvbhute 2006-12-19 02:19:14 UTC
I have installed dbg packages as suggested to add debugging info, but the apps are not crashing! I mean - the crash is not reproducible so I cannot generate the better stack trace. However, this will be useful for the next time it occurs. Thanks.
Comment 3 Tim-Philipp Müller 2006-12-19 11:43:50 UTC
In particular, please have these two packages installed:

  sudo apt-get install libglib2.0-0-dbg libgstreamer0.10-0-dbg


If you know how to do this, you could try the following (someone mentioned it only happens when users log in for the first time, but I haven't been able to reproduce this myself yet):

  - log out from your desktop environment (GNOME presumably)
  - switch to a text console and log in as a normal user (CTRL+ALT+F1 usually)
  - do     rm -rf ~/.gstreamer-0.10
  - switch back to your login manager (CTRL+ALT+F7 usually)
  - log in and see if the crash happens again

Comment 4 rvbhute 2006-12-19 16:04:17 UTC
I'd already installed those two when I installed dbg packages. Regarding your second suggestion, there is no crash. I played mp3 files even, after finishing the procedure.
Comment 5 Tim-Philipp Müller 2006-12-19 17:04:51 UTC
*** Bug 362311 has been marked as a duplicate of this bug. ***
Comment 6 Tim-Philipp Müller 2006-12-19 17:14:38 UTC
> Regarding your second suggestion, there is no crash. I played mp3
> files even, after finishing the procedure.

Shame, thanks for trying.

No idea what the problem is then. The stack trace would seem to indicate a problem in GLib's GSLice allocator to me then (all our calls to g_object_new() in gstregistryxml are without additional properties, so it can't be that we're passing wrong args there). Hard to say without a better stack trace or a way to reproduce.

There is a whole bunch of similar bugs, all of which are crashes in g_slice_alloc() from g_type_create_instance(); many of those seem to be from other panel applets as well.

Couldn't find any bugs in GLib that match this issue though, so chances are fairly good that this is due to some memory corruption caused shortly before and throwing off the GLib allocator.

Even more so since I don't see how gst_registry_xml_write_cache() would cause a new object to be created.

Possibly related:
 - bug #379690: crash in g_free()/free() from gst_registry_xml_write_cache()
 - bug #354483: crash in xmlTextReaderRead() (!!!) from gst_registry_xml_write_cache()

Comment 7 Tim-Philipp Müller 2006-12-19 17:16:31 UTC
*** Bug 379379 has been marked as a duplicate of this bug. ***
Comment 8 Tim-Philipp Müller 2006-12-19 17:22:40 UTC
Another variation:

 - bug #375085: trace with gst_type_find_factory_get_list(), g_type_class_ref(),
   and g_type_instance_create() from gst_registry_xml_write_cache()
Comment 9 Tim-Philipp Müller 2007-01-08 22:43:07 UTC
Probably due to late g_thread_init(), see bug #391278. Closing until someone can reproduce a core >= current CVS (if it's still a problem I'm sure someone will, probably sooner rather than later).

*** This bug has been marked as a duplicate of 391278 ***