From owner-freebsd-current Sun May 12 14:28:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id BDCE537B401 for ; Sun, 12 May 2002 14:28:19 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g4CLRgHA003859; Sun, 12 May 2002 23:27:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar Cc: current@FreeBSD.ORG Subject: Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal In-Reply-To: Your message of "Sun, 12 May 2002 14:22:36 PDT." <20020512212236.GB20876@dhcp01.pn.xcllnt.net> Date: Sun, 12 May 2002 23:27:42 +0200 Message-ID: <3858.1021238862@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 <20020512212236.GB20876@dhcp01.pn.xcllnt.net>, 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 Moolenaar USPA: A-39004 marcel@xcllnt.net > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message