Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Sep 1997 13:51:14 +0200 (SAT)
From:      Graham Wheeler <gram@cdsec.com>
To:        julian@whistle.com (Julian Elischer)
Cc:        hackers@freebsd.org, freebsd-bugs@freebsd.org
Subject:   Re: Memory leak in getservbyXXX?
Message-ID:  <199709151151.NAA27754@cdsec.com>
In-Reply-To: <3419A0D8.7DE14518@whistle.com> from "Julian Elischer" at Sep 12, 97 01:06:48 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Mike Smith wrote:
> > 
> > > > If it's a memory leak then it sounds like it's inside the stdio
> > > > library, possibly in fopen()/fclose().  Without more data it's going to
> > > > be hard to track this one.
> > >
> > > Tell me about it 8-(
> > >
> > > It does seem like a memory leak, as the memory use reported by top grows
> > > over time. I have memory allocation debugging code which confirms that
> > > I have no leaks in my code (at least of C++ objects), and the fact that
> > > older sites have been running for months seems to confirm this.
> > 
> > OK.  More to the point then it sounds like it's a memory leak due to
> > some change in stdio.  That's getting slightly easier to chase I 
> 
> they aren't using the threaded libc are they?

How would I know this? I'm not explicitly saying which; just doing a normal
link. I have a static, a shared, and a profiled libc in /usr/lib.

Does the threaded libc have a different name, or is it now the default,
or does it depend on how libc is compiled? 

Incidentally, going back to the original problem:

I now have about 15 core dumps. Two happened when the program itself
dumped the core, the rest were caused by sending SIGABRTs after
the program started spinning. These are all after I added the
setservent(1) call at the start, so they no longer happen in
getservbyXXX. However, in each case the stack backtrace ends in 
malloc or free.

I also have every `new' followed by an assert, and have set the D, A 
and Z options to malloc; none of these have made a difference. So
I'm starting to believe that the problem is heap corruption rather than
heap exhaustion, so tools like mprof are probably not much use. It's
interesting though that this only happens with 2.2.2, and not under 2.1.0;
mayhap it's a problem with gcc somewhere.

regards
graham
-- 
Dr Graham Wheeler                          E-mail: gram@cdsec.com
Citadel Data Security                      Phone:  +27(21)23-6065/6/7
Internet/Intranet Network Specialists      Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks         Fax:    +27(21)24-3656
Data Security Products                     WWW:    http://www.cdsec.com/






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709151151.NAA27754>