Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: > > That one's easy to diagnose: > > You change your windowsize while tcsh happened to be in free(3) (frame #12). I've been seeing malloc crashes in tcsh as well, but not in the same codepath (they occur during a 'cd' operation). I have a crashdump somewhere but I can't find it at the moment :( Kris msg38298/pgp0.pgp Description: PGP signature
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
Marcel Moolenaar wrote: > On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: > > It is not legal to recursively call malloc/free/realloc, and therefore > > you should either protect all calls to malloc/free/realloc by blocking > > signals or better: not call them in signal handlers. > > Ok, thanks. I guess we have a genuine tcsh(1) bug here. > > Who's maintaining tcsh? Can he/she suggest what to do or otherwise > take it from here? The Single UNIX Specification Standard and POSIX both explicitly state that it is not safe to call memory management functions from signal handlers. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
On Sun, May 12, 2002 at 03:32:49PM -0700, Mark Peek wrote: > > I've been maintaining tcsh. Can you file a PR and assign it to me? > I'll follow up with the tcsh owner to resolve the problem. PR: bin/38006. Backtrace and and libc hack to easily reproduce the condition included. Thanks, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
At 3:20 PM -0700 5/12/02, Marcel Moolenaar wrote: >On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: >> >> It is not legal to recursively call malloc/free/realloc, and therefore >> you should either protect all calls to malloc/free/realloc by blocking >> signals or better: not call them in signal handlers. > >Ok, thanks. I guess we have a genuine tcsh(1) bug here. > >Who's maintaining tcsh? Can he/she suggest what to do or otherwise >take it from here? I've been maintaining tcsh. Can you file a PR and assign it to me? I'll follow up with the tcsh owner to resolve the problem. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: > > It is not legal to recursively call malloc/free/realloc, and therefore > you should either protect all calls to malloc/free/realloc by blocking > signals or better: not call them in signal handlers. Ok, thanks. I guess we have a genuine tcsh(1) bug here. Who's maintaining tcsh? Can he/she suggest what to do or otherwise take it from here? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
< said: > The correct solution is probably to set a flag in the signal handler > and resize the buffer before the next line is read. Or, somewhat less optimally, to block SIGWINCH (and any other signals with similar handler behavior) around calls to malloc and free. This is still not *correct*, mind you, but will make the condition less likely. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
That one's easy to diagnose: You change your windowsize while tcsh happened to be in free(3) (frame #12). tcsh gets the SIGWINSZ (sp?) signal, and tries to allocate a buffer, probably a new line-edit buffer, calls malloc(3) (fram #4) and malloc abort(3)'s the program. It is not legal to recursively call malloc/free/realloc, and therefore you should either protect all calls to malloc/free/realloc by blocking signals or better: not call them in signal handlers. The correct solution is probably to set a flag in the signal handler and resize the buffer before the next line is read. Poul-Henning In message <[EMAIL PROTECTED]>, Marcel Moolenaar writ es: >Gang, > >I occasionally get tcsh coredumps (signal 6). I mostly ignored it, >but today I decided to track it down for once. This is the backtrace: > >(gdb) bt >#0 0x808e4a3 in access () >#1 0x80ba9fa in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:78 >#2 0x80b97a9 in wrtwarning (p=0x80ef54e "in free():") at >/usr/src/lib/libc/../libc/stdlib/malloc.c:314 >#3 0x80b97c8 in wrtwarning (p=0x80ef54e "in free():") at >/usr/src/lib/libc/../libc/stdlib/malloc.c:315 >#4 0x80ba5aa in malloc (size=1644) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1093 >#5 0x8079163 in smalloc (n=1644) at >/usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:505 >#6 0x80757d8 in ReBufferDisplay () at >/usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:506 >#7 0x8077cf9 in ChangeSize (lins=24, cols=80) at >/usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:1742 >#8 0x8071542 in check_window_size (force=0) at >/usr/src/bin/csh/../../contrib/tcsh/ed.init.c:128 >#9 0x8071564 in window_change (snum=28) at >/usr/src/bin/csh/../../contrib/tcsh/ed.init.c:148 >#10 >#11 0x80baa8f in memcpy () >#12 0x80ba6c9 in free (ptr=0x814f600) at >/usr/src/lib/libc/../libc/stdlib/malloc.c:1125 >#13 0x8079287 in sfree (p=0x814f600) at >/usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:586 >#14 0x805c2ca in blkfree (av0=0x814f600) at >/usr/src/bin/csh/../../contrib/tcsh/sh.misc.c:169 >#15 0x8057600 in backeval (cp=0x8150900, literal=0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:842 >#16 0x80574e8 in dobackp (cp=0x8147060, literal=0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:784 >#17 0x8056aa1 in globexpand (v=0x814ac54) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:386 >#18 0x8057171 in globall (v=0x814ac50) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:632 >#19 0x80622c1 in set1 (var=0x814acf0, vec=0x814ac50, head=0x8130fc4, flags=2) at >/usr/src/bin/csh/../../contrib/tcsh/sh.set.c:616 >#20 0x806227a in set (var=0x814acf0, val=0x8147060, flags=2) at >/usr/src/bin/csh/../../contrib/tcsh/sh.set.c:601 >#21 0x8061a41 in doset (v=0x814f200, c=0x814cce0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.set.c:292 >#22 0x8053428 in func (t=0x814cce0, bp=0x80f4a44) at >/usr/src/bin/csh/../../contrib/tcsh/sh.func.c:149 >#23 0x80608d7 in execute (t=0x814cce0, wanttty=634, pipein=0x0, pipeout=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:657 >#24 0x8060b15 in execute (t=0x814ccc0, wanttty=634, pipein=0x0, pipeout=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:734 >#25 0x804a847 in process (catch=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:2125 >#26 0x804a0f9 in srcunit (unit=3, onlyown=1, hflg=0, av=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1661 >#27 0x8049cce in srcfile (f=0x814b700 "USER", onlyown=1, flag=0, av=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1468 >#28 0x8049c70 in srccat (cp=0x814ca00, dp=0x80f64a4) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1441 >#29 0x8049973 in main (argc=0, argv=0xbfbffaa4) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1301 > >Apparently what's happening is that tcsh get's interrupted while >in free() and the signal handler itself calls malloc(). Note that >this typically happens when I open a new GNOME terminal. > >I guess the grand question is: is this a genuine bug or just a nasty >side effect of our malloc options? > >-- > Marcel MoolenaarUSPA: A-39004 [EMAIL PROTECTED] > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
Gang, I occasionally get tcsh coredumps (signal 6). I mostly ignored it, but today I decided to track it down for once. This is the backtrace: (gdb) bt #0 0x808e4a3 in access () #1 0x80ba9fa in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:78 #2 0x80b97a9 in wrtwarning (p=0x80ef54e "in free():") at /usr/src/lib/libc/../libc/stdlib/malloc.c:314 #3 0x80b97c8 in wrtwarning (p=0x80ef54e "in free():") at /usr/src/lib/libc/../libc/stdlib/malloc.c:315 #4 0x80ba5aa in malloc (size=1644) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1093 #5 0x8079163 in smalloc (n=1644) at /usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:505 #6 0x80757d8 in ReBufferDisplay () at /usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:506 #7 0x8077cf9 in ChangeSize (lins=24, cols=80) at /usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:1742 #8 0x8071542 in check_window_size (force=0) at /usr/src/bin/csh/../../contrib/tcsh/ed.init.c:128 #9 0x8071564 in window_change (snum=28) at /usr/src/bin/csh/../../contrib/tcsh/ed.init.c:148 #10 #11 0x80baa8f in memcpy () #12 0x80ba6c9 in free (ptr=0x814f600) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1125 #13 0x8079287 in sfree (p=0x814f600) at /usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:586 #14 0x805c2ca in blkfree (av0=0x814f600) at /usr/src/bin/csh/../../contrib/tcsh/sh.misc.c:169 #15 0x8057600 in backeval (cp=0x8150900, literal=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:842 #16 0x80574e8 in dobackp (cp=0x8147060, literal=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:784 #17 0x8056aa1 in globexpand (v=0x814ac54) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:386 #18 0x8057171 in globall (v=0x814ac50) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:632 #19 0x80622c1 in set1 (var=0x814acf0, vec=0x814ac50, head=0x8130fc4, flags=2) at /usr/src/bin/csh/../../contrib/tcsh/sh.set.c:616 #20 0x806227a in set (var=0x814acf0, val=0x8147060, flags=2) at /usr/src/bin/csh/../../contrib/tcsh/sh.set.c:601 #21 0x8061a41 in doset (v=0x814f200, c=0x814cce0) at /usr/src/bin/csh/../../contrib/tcsh/sh.set.c:292 #22 0x8053428 in func (t=0x814cce0, bp=0x80f4a44) at /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:149 #23 0x80608d7 in execute (t=0x814cce0, wanttty=634, pipein=0x0, pipeout=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:657 #24 0x8060b15 in execute (t=0x814ccc0, wanttty=634, pipein=0x0, pipeout=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:734 #25 0x804a847 in process (catch=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:2125 #26 0x804a0f9 in srcunit (unit=3, onlyown=1, hflg=0, av=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1661 #27 0x8049cce in srcfile (f=0x814b700 "USER", onlyown=1, flag=0, av=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1468 #28 0x8049c70 in srccat (cp=0x814ca00, dp=0x80f64a4) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1441 #29 0x8049973 in main (argc=0, argv=0xbfbffaa4) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1301 Apparently what's happening is that tcsh get's interrupted while in free() and the signal handler itself calls malloc(). Note that this typically happens when I open a new GNOME terminal. I guess the grand question is: is this a genuine bug or just a nasty side effect of our malloc options? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
