From owner-freebsd-current Sat Feb 8 14:54:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA05690 for current-outgoing; Sat, 8 Feb 1997 14:54:21 -0800 (PST) Received: from mail2.uunet.ca (mail2.uunet.ca [142.77.1.15]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05678 for ; Sat, 8 Feb 1997 14:54:14 -0800 (PST) Received: from why.whine.com ([205.150.249.1]) by mail2.uunet.ca with ESMTP id <122914-14202>; Sat, 8 Feb 1997 17:54:10 -0500 Received: from why (why [205.150.249.1]) by why.whine.com (8.8.5/8.7.3) with SMTP id RAA15192; Sat, 8 Feb 1997 17:53:35 -0500 (EST) Date: Sat, 8 Feb 1997 17:53:35 -0500 From: Andrew Herdman X-Sender: andrew@why To: Poul-Henning Kamp cc: Andrew Herdman , current@freebsd.org Subject: Re: Make world of Current dies with weird errors. In-Reply-To: <8301.855419376@critter.dk.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 8 Feb 1997, Poul-Henning Kamp wrote: > In message , Andrew Herdman writes > : > >When i'm doing a make world, i get the following errors. > > > >make cleandir > > > > > > > >===> 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 ) 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