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.


In message <[EMAIL PROTECTED]>, Marcel Moolenaar writ
>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 
>#3  0x80b97c8 in wrtwarning (p=0x80ef54e "in free():") at 
>#4  0x80ba5aa in malloc (size=1644) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1093
>#5  0x8079163 in smalloc (n=1644) at 
>#6  0x80757d8 in ReBufferDisplay () at 
>#7  0x8077cf9 in ChangeSize (lins=24, cols=80) at 
>#8  0x8071542 in check_window_size (force=0) at 
>#9  0x8071564 in window_change (snum=28) at 
>#10 <signal handler called>
>#11 0x80baa8f in memcpy ()
>#12 0x80ba6c9 in free (ptr=0x814f600) at 
>#13 0x8079287 in sfree (p=0x814f600) at 
>#14 0x805c2ca in blkfree (av0=0x814f600) at 
>#15 0x8057600 in backeval (cp=0x8150900, literal=0) at 
>#16 0x80574e8 in dobackp (cp=0x8147060, literal=0) at 
>#17 0x8056aa1 in globexpand (v=0x814ac54) at 
>#18 0x8057171 in globall (v=0x814ac50) at 
>#19 0x80622c1 in set1 (var=0x814acf0, vec=0x814ac50, head=0x8130fc4, flags=2) at 
>#20 0x806227a in set (var=0x814acf0, val=0x8147060, flags=2) at 
>#21 0x8061a41 in doset (v=0x814f200, c=0x814cce0) at 
>#22 0x8053428 in func (t=0x814cce0, bp=0x80f4a44) at 
>#23 0x80608d7 in execute (t=0x814cce0, wanttty=634, pipein=0x0, pipeout=0x0) at 
>#24 0x8060b15 in execute (t=0x814ccc0, wanttty=634, pipein=0x0, pipeout=0x0) at 
>#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 
>#27 0x8049cce in srcfile (f=0x814b700 "USER", onlyown=1, flag=0, av=0x0) at 
>#28 0x8049c70 in srccat (cp=0x814ca00, dp=0x80f64a4) at 
>#29 0x8049973 in main (argc=0, argv=0xbfbffaa4) at 
>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

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

Reply via email to