On 08/15/2012 08:40 PM, Eli Zaretskii wrote:

>> Date: Mon, 13 Aug 2012 22:24:08 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dmantipov@yandex.ru, 12007@debbugs.gnu.org
>>
>> Perhaps related, the current trunk (revision 109586) segfaults on
>> startup ("emacs -Q") on GNU/Linux, with the following backtrace:
>>
>>    #0  0x00007ffff5bc0131 in g_type_check_instance_cast ()
>>       from /usr/lib/libgobject-2.0.so.0
>>    #1  0x00000000005d6de6 in xg_mark_data () at gtkutil.c:2173
>>    #2  0x0000000000692f28 in Fgarbage_collect () at alloc.c:5472
>>    #3  0x000000000068bd27 in maybe_gc () at lisp.h:3536
>>    #4  0x00000000006bc2ab in eval_sub (form=23619014) at eval.c:2056
>>    #5  0x0000000000706a9c in readevalloop (readcharfun=15433282,
>>        stream=0x168a720, sourcename=23641873, printflag=0, unibyte=15317634,
>>        readfun=15317634, start=15317634, end=15317634) at lread.c:1814
>>    #6  0x0000000000704998 in Fload (file=23634305, noerror=15317682,
>>        nomessage=15317682, nosuffix=15317634, must_suffix=15317634)
>>        at lread.c:1308
>
> Today's trunk still crashes on startup.  Can this be fixed, please?

I don't know whether you have received my previous e-mail, but it was:

Eli, please review a fix.

This looks simple: it's wrong to look at with f->output_data.XXX without
checking f->output_method first, so, FRAME_X_OUTPUT (f) may be non-zero
for TTY frames, and segfault comes when xg_mark_data looks at initial
("F1") frame with non-zero f->output_data.tty member.

Dmitry

P.S. BTW, this is X/GTK bug rather that GC bug.