Re: Reproducible gtk crash

[Simon Josefsson]

"Jan D." <address@hidden> writes:

> Simon Josefsson wrote:
>
>>Shortly after the last crash, I got another one...
>>
>>This crash seem reproducible, I rebuilt today's CVS and still get the
>>problem.
>>
>>The crash happen when I click "Save" on a MIME attachment in Gnus, and
>>Emacs is popping up a GTK Save As Dialog.  It crashes, with the
>>backtrace below.
>>
>>This is on an up to date Debian testing x86 machine.
>>
>>#0  abort () at emacs.c:442
>>#1  0x080fbd8e in XTread_socket (sd=0, expected=1, hold_quit=0xbfffdcb4)
>>    at xterm.c:6972
>>#2  0x0812c015 in read_avail_input (expected=1) at keyboard.c:6640
>>#3  0x0812c1fc in handle_async_input () at keyboard.c:6782
>>#4  0x0812c241 in input_available_signal (signo=29) at keyboard.c:6821
>>#5  <signal handler called>
>>#6  0x407883e7 in select () from /lib/tls/libc.so.6
>>#7  0x080bc3d1 in x_menu_wait_for_event (data=0x0) at xmenu.c:1176
>>#8  0x0811e45c in xg_get_file_name (f=0x0, prompt=0x8fdfe28 "\220\314q\b\002",
>>    default_filename=0x0, mustmatch_p=-1073749936, only_dir_p=0)
>>    at gtkutil.c:1354
>>
>
> This makes no sense.  XTread_socket does not contain any call to abort, 
> and the line in the backtrace is 'return -1'.  Can you see if it is 
> possible to step up in the debugger and see where in XTread_socket the 
> abort happens?

The problem seem to be different each time, and some time it doesn't
crash but only hang.  I couldn't even type Ctrl-C to get to the gdb
prompt.  It seems thread related, gdb says several threads are created
when the "Save as" dialog is about to show up.  Below is another gdb
session when this happens (all messages about threads are printed
after I click on "Save as" and when the dialog appears).

Sometimes the GTK widget appears functional, e.g., I can change
directory etc and see those files.  However, I remember that the
dialog used to be different, it was the normal directory/files GTK
dialog.  Now it is some minimalistic version where there is a
pull-down menu for "Home" etc.  Maybe the problem is in my GTK
libraries?  I'm using Debian testing.

Thanks.

[Thread debugging using libthread_db enabled]
[New Thread 1083202432 (LWP 31030)]
[New Thread 1147771824 (LWP 401)]
[New Thread 1148300208 (LWP 402)]
[Switching to Thread 1083202432 (LWP 31030)]

Breakpoint 1, abort () at emacs.c:442
442       kill (getpid (), SIGABRT);
(gdb) up
#1  0x0816f28e in emacs_blocked_malloc (size=4294967295) at alloc.c:1035
1035    }
(gdb) bt
#0  abort () at emacs.c:442
#1  0x0816f28e in emacs_blocked_malloc (size=4294967295) at alloc.c:1035
#2  0x407260bb in malloc () from /lib/tls/libc.so.6
#3  0x0000000a in ?? ()
#4  0x4047e367 in g_malloc () from /usr/lib/libglib-2.0.so.0
Previous frame inner to this frame (corrupt stack?)
(gdb) l
1035    }
1036
1037
1038    /* This function is the realloc hook that Emacs uses.  */
1039
1040    static void *
1041    emacs_blocked_realloc (ptr, size)
1042         void *ptr;
1043         size_t size;
1044    {
(gdb) down
#0  abort () at emacs.c:442
442       kill (getpid (), SIGABRT);
(gdb) up
#1  0x0816f28e in emacs_blocked_malloc (size=4294967295) at alloc.c:1035
1035    }
(gdb) l
1030      __malloc_hook = emacs_blocked_malloc;
1031      UNBLOCK_INPUT;
1032
1033      /* fprintf (stderr, "%p malloc\n", value); */
1034      return value;
1035    }
1036
1037
1038    /* This function is the realloc hook that Emacs uses.  */
1039
(gdb) up
#2  0x407260bb in malloc () from /lib/tls/libc.so.6
(gdb) up
#3  0x0000000a in ?? ()
(gdb) up
#4  0x4047e367 in g_malloc () from /usr/lib/libglib-2.0.so.0
(gdb) up
Initial frame selected; you cannot go up.
(gdb) q