Re: deadlock caused by gettext usage in a signal handler

[Guillaume Chazarain <guichaz@xxxxxxxx>]

Le Tue, 4 Dec 2007 20:30:17 +0000,
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> a écrit :

> but I'm starting to think the issue is more widespread.

Definitely :-(

Here is a stack trace without gettext in it:

0x0000003c3f0dcf78 in __lll_mutex_lock_wait () from /lib64/libc.so.6
#0  0x0000003c3f0dcf78 in __lll_mutex_lock_wait () from /lib64/libc.so.6
#1  0x0000003c3f074cb7 in _L_lock_14740 () from /lib64/libc.so.6
#2  0x0000003c3f073b11 in *__GI___libc_free (mem=0x3c3f34c960) at malloc.c:3620
#3  0x0000000000431f02 in savehistfile (
    fn=0x8a1690 "/user/gchazara/home/.zsh_history", err=1, 
    writeflags=<value optimized out>) at hist.c:2091
#4  0x000000000040dd6d in zexit (val=1, from_where=<value optimized out>)
    at builtin.c:4181
#5  0x0000000000465637 in zhandler (sig=-512) at signals.c:540
#6  <signal handler called>
#7  0x0000003c3f07006a in _int_free (av=0x3c3f34c960, mem=0x8b02c0)
    at malloc.c:4662
#8  0x0000003c3f073b1c in *__GI___libc_free (mem=0xb65d60) at malloc.c:3622
#9  0x0000000000438965 in ingetc () at input.c:261
#10 0x000000000043338d in ihgetc () at hist.c:241
#11 0x000000000044122b in gettok () at lex.c:631
#12 0x0000000000441a38 in yylex () at lex.c:347
#13 0x000000000045cef7 in parse_event () at parse.c:449
#14 0x0000000000437348 in loop (toplevel=1, justonce=0) at init.c:128
#15 0x0000000000438051 in zsh_main (argc=<value optimized out>, 
    argv=0x7ffff4980ef8) at init.c:1280
#16 0x0000003c3f01dab4 in __libc_start_main (main=0x40cca0 <main>, argc=1, 
    ubp_av=0x7ffff4980ef8, init=<value optimized out>, 
    fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7ffff4980ee8) at libc-start.c:222
#17 0x000000000040cc09 in _start ()

A deadlock with free() this time.

Here is more information about how to reproduce these deadlocks:

Download a snapshot of gsh:
http://repo.or.cz/w/gsh.git?a=snapshot;h=9a90d28f9ad0e64c45202522b26ff6c13f10f795;sf=tgz

Run this loop:

while : ; do ./gsh.py --command=: localhost localhost localhost; done

This assumes that running 'ssh localhost' will lead you to a Zsh
instance. This should accumulate deadlocked Zsh processes that you can
see with: pstree -a -h -p -u $USER|grep '^zsh,'|cut -d, -f2

I don't think it's the first time I saw hung Zsh processes, but this
commit in my gsh software made the problem appears more easily:

http://repo.or.cz/w/gsh.git?a=commitdiff;h=9a90d28f9ad0e64c45202522b26ff6c13f10f795

It replaces builtin echo invocations with actual /bin/echo forkings.

Hope that helps.

-- 
Guillaume