Date: Sat, 8 Feb 1997 17:53:35 -0500 From: Andrew Herdman <andrew@why.whine.com> To: Poul-Henning Kamp <phk@critter.dk.tfs.com> Cc: Andrew Herdman <andrew@why.whine.com>, current@freebsd.org Subject: Re: Make world of Current dies with weird errors. Message-ID: <Pine.BSF.3.95.970208173817.14716A-100000@why> In-Reply-To: <8301.855419376@critter.dk.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Feb 1997, Poul-Henning Kamp wrote:
> In message <Pine.BSF.3.95.970207212402.1098A-100000@why>, Andrew Herdman writes
> :
> >When i'm doing a make world, i get the following errors.
> >
> >make cleandir
> >
> ><cleaning stuff going on here>
> >
> >===> lib/libtelnet
> >make in free(): warning: chunk is already free.
> >make in free(): warning: chunk is already free.
> >make in free(): warning: chunk is already free.
>
> Off the top of my head I'd say RAM/cache HW problem, but I have heard
> other reports about the same phenomena enough to find it slightly
> worrisome, and I have not been able to reproduce the problem here.
>
> If you can reliably reproduce this, and have time & courage, here's
> how to proceed:
>
> in your chroot environment:
>
> ln -s A /etc/malloc.conf
> reproduce the problem
> you should now have a make.core file somewhere.
> gdb /usr/src/.../make make.core
> find the problem
> make a patch
> send-pr
Well I had some courage. I can reliably reproduce the bug, and have with
a make re-compiled with -g, and the malloc trick i now have a nice core
file. As for using gdb for debugging... err well I don't now much about
it... i've seen the bt command used extensively and this is what i got:
Core was generated by `make'.
Program terminated with signal 6, Abort trap.
Cannot access memory at address 0x654f0.
#0 0x807de11 in ?? ()
(gdb) bt
#0 0x807de11 in ?? ()
#1 0x807d6e3 in ?? ()
#2 0x807c232 in ?? ()
#3 0x807c270 in ?? ()
#4 0x807d24b in ?? ()
#5 0x807d432 in ?? ()
#6 0x12731 in Lst_Destroy (l=0x588c0, freeProc=0)
at /usr/src/usr.bin/make/lst.lib/lstDestroy.c:99
#7 0xfb2b in TargFreeGN (gnp=0x55d00) at targ.c:219
#8 0x1270b in Lst_Destroy (l=0x182e0, freeProc=0xfae0 <TargFreeGN>)
at /usr/src/usr.bin/make/lst.lib/lstDestroy.c:93
#9 0xf9d7 in Targ_End () at targ.c:139
#10 0xa000 in main (argc=3, argv=0xefbfd798) at main.c:804
I have the core and the program that created, and if you want I can leave
them somewhere for someone who knows what they are doing to take a peek at
them. I will help where I can of course, but this one is bigger than I
am.
>
> The actual complaint from the program means that some piece of memory
> that was allocated with malloc is freed twice. The fact that it's
> called a "chunk" tells that it is <= 2048 bytes long.
>
> If you can get a stacktrace, you will find the pointer to this piece
> of memory in the topmost call to free() or realloc().
>
> Try to see if you can compile a make with "-g" and still reproduce
> the problem.
Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970208173817.14716A-100000>