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 413635 - gaim crashed with SIGSEGV in gst_audio_clock_new()
gaim crashed with SIGSEGV in gst_audio_clock_new()
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.x
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-03-01 21:43 UTC by Sebastien Bacher
Modified: 2007-05-03 11:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Sebastien Bacher 2007-03-01 21:43:30 UTC
That bug has been opened on https://launchpad.net/bugs/86489

"Binary package hint: gaim

just crashed while restarting session
...
"

Debug backtrace for the crash:

Thread 1 (process 7394)

  • #0 gst_audio_clock_new
    at gstaudioclock.c line 121
  • #1 gst_base_audio_sink_init
    at gstbaseaudiosink.c line 177
  • #2 IA__g_type_create_instance
    at gtype.c line 1561
  • #3 g_object_constructor
    at gobject.c line 1041
  • #4 IA__g_object_newv
    at gobject.c line 937
  • #5 IA__g_object_new_valist
    at gobject.c line 981
  • #6 IA__g_object_new
    at gobject.c line 795
  • #7 gst_element_factory_create
    at gstelementfactory.c line 371
  • #8 gst_element_factory_make
    at gstelementfactory.c line 442
  • #9 _gst_parse__yyparse
    at ./grammar.y line 508
        yyresult = <value optimized out>
        yyerrstatus = 0
        yytoken = 4
        yymsgbuf = "\000���\000\222��9~��\000\222������i\204�������R���T��X\030���\024\220���������X\030﷼T��\020���B���\020\032��\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\226���\037\003\000\000\000���\004�\t\000�T��\000\222����\220��\032\220������R
        yymsg = 0xb4eec198 ""
        yymsg_alloc = 128
        yyssa = {0, 3, 16, 2, -2718, -18461, -4892, -18556, -17701, -18449, 26296, -18680, -12300, -18448, 23140, 2069, 
  1, 0, -16216, -19218, -16574, -18449, 23212, 2069, 19, 0, -16200, -19218, -12300, -18448, 1, 0, -17397, 7, -16268, 
  -19218, -16268, -19218, -16028, -19218, -17701, -18449, 6232, -18449, 57, 0, 8908, -18461, 5044, -18461, 0, 0, 25832, 
  -2175, -15996, -19218, -28934, -7393, 0, 0, -12300, -18448, 23140, 2069, 1, 0, -16120, -19218, -16574, -18449, -3177, 
  -18461, 31452, -18461, 15996, -18461, 1, 0, 17, 0, 29806, 3, -16172, -19218, -16172, -19218, -15932, -19218, -16233, 
  28301, 6232, -18449, 57, 0, 8908, -18461, 6468, -18461, 1, 0, -16234, 28301, 1, 0, 21804, -18461, 0, 0, 0, 0, 1, 0, 
  799, 0, 0, 0, 6232, -18449, -2922, -18461, 31452, -18461, 21692, -18461, 1, 0, -12300, -18448, 6672, -18449, -15944, 
  -19218, -15916, -19218, -16125, -18449, 21692, -18461, -15944, -19218, -10180, -18448, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 
  0, -15904, -19218, 6232, -18449, -3120, -18461, 6162, 3, -15932, -19218, 24, 0, 28, -20080, -12, -18577, -15872, 
  -19218, 6232, -18449, -2922, -18461, -14866, 98, -16233, 28301, 0, 0, -28160, -18452, 5352, -20080, 5352, -20080, 
  -15992, -19218, -32179, -18454, 4, 0, -28160, -18452, -15960, -19218, -31963, -18454}
        yyss = (yytype_int16 *) 0xb4eec000
        yyssp = (yytype_int16 *) 0xb4eec006
...
Comment 1 Tim-Philipp Müller 2007-04-21 15:39:38 UTC
The stack trace looks good and there are two seemingly identical crashers, but it somehow just doesn't make sense to me.

 - g_object_new() can't fail AFAIK
 - obj->foo=x can't fail either if obj is a valid allocated
   object struct as g_object_new() should return it

Maybe gaim or something else is thrashing the memory?

Is this bug reproducable?

What would also be interesting is the value of the 'aclock' variable in the gst_audio_clock_new() function/frame when it crashes.
Comment 2 Tim-Philipp Müller 2007-05-03 11:02:48 UTC
Closing as INCOMPLETE for now, since there isn't really much we can do about it with the info we have and it JustDoesn'tReallyMakeSense(tm) code-wise.

If someone can reproduce this, please run gaim in valgrind to see what comes up there.