Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-13 Thread Kris Kennaway
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)

Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-12 Thread Terry Lambert
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

Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-12 Thread Marcel Moolenaar
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, -- M

Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-12 Thread Mark Peek
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

Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-12 Thread Marcel Moolenaar
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 hav

Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-12 Thread Garrett Wollman
< 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*,

Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal

2002-05-12 Thread Poul-Henning Kamp
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 recurs