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 <signal handler called> >#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 > -- 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
