From owner-freebsd-bugs  Tue Sep 16 08:28:17 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA00332
          for bugs-outgoing; Tue, 16 Sep 1997 08:28:17 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA00323
          for <freebsd-bugs@FreeBSD.ORG>; Tue, 16 Sep 1997 08:28:12 -0700 (PDT)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id QAA02510;
	Tue, 16 Sep 1997 16:44:56 +0200 (CEST)
To: Graham Wheeler <gram@cdsec.com>
cc: mike@smith.net.au (Mike Smith), freebsd-bugs@FreeBSD.ORG
Subject: Re: Memory leak in getservbyXXX? 
In-reply-to: Your message of "Sat, 12 Sep 1997 10:40:10 +0200."
             <199709120840.KAA20043@cdsec.com> 
Date: Tue, 16 Sep 1997 16:44:56 +0200
Message-ID: <2508.874421096@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


(Sorry for the delay)

I've looked at these stack traces, and I'm pretty sure I know the
smell of this one.

My guess number one is that malloc bails out and that the topmost 
couple of entries come from the __cleanup that happens in abort().

Make sure that filedescriptor #2 (as in: write(2,"FOO!",4)) is open
and points to something that will let you read the message, and look
for messages there.

Also:
	ln -s AJ /etc/malloc.conf

This will make finding the problem faster in most cases.

My guess number two is memory corruption.

The only syscalls/libs called from phkmalloc are sbrk(), write(), 
madvise(), mmap(), and abort().  At least as far as I remember.

Hope this helps.

Poul-Henning

In message <199709120840.KAA20043@cdsec.com>, Graham Wheeler writes:
>> > In each case, while the location in our own code varies, the stack trace
>> > always ends in a call to getservbyname() or getservbyport(). These in turn
>> > are calling either malloc() or free(), which in turn seem to be calling
>> > fstat() (at least according to the stack backtrace).
>> 
>> That's fairly odd; malloc()/free() do not call fstat().   Are you using 
>> the system malloc() or the GNU version?  
>
>Here are three sample core dumps:
>
>#0  0x52220 in fstat ()
>#1  0x95000 in ?? ()
>#2  0x5256e in free ()
>#3  0x46312 in fclose ()
>#4  0x334af in endservent ()
>#5  0x2f84e in getservbyname ()
>
>
>
>#0  0x51a60 in fstat ()
>#1  0x63f54 in buffer ()
>#2  0x51da2 in fstat ()
>#3  0x524f6 in malloc ()
>#4  0x50ba9 in __smakebuf ()
>#5  0x461c0 in __srefill ()
>
>
>#0  0x52220 in fstat ()
>#1  0x83000 in ?? ()
>#2  0x5256e in free ()
>#3  0x46312 in fclose ()
>#4  0x334af in endservent ()
>#5  0x2f79a in getservbyport ()

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."