ePN and memory leaks

Stanley Hopcroft Stanley.Hopcroft at IPAustralia.Gov.AU
Tue Jan 14 00:24:48 CET 2003


Dear Sir,

I am writing to thank you for your helpful letter and say,

On Mon, Jan 13, 2003 at 03:32:00PM -0500, atonns at mail.ivillage.com wrote:
> Has anyone else done an in-depth investigation of memory leaks in ePN and/or
> custom checks written for ePN?

> > -----Original Message-----
> > From: Stanley Hopcroft [mailto:Stanley.Hopcroft at IPAustralia.Gov.AU]
> > Sent: Monday, December 30, 2002 10:31 PM
> > To: atonns at mail.ivillage.com
> > Cc: nagios-users at lists.sourceforge.net
> > Subject: Re: [Nagios-users] ePN and memory leaks
> > 
> > > Are there any suggestions for finding memory leaks in ePN? 
> > (I'm going to be
> > > looking at Apache::Leak and Devel::Leak, but there might be 
> > other debug
> > > options in nagios I'm not aware of).
> > >
> > 
> > Not that I am aware of. It sounds like you are on the right track
> > though.
> 
> Well, I've run several tests with both Apache::Leak and Devel::Leak and have
> found that it's not my code that's leaking, but either p1.pl or mini_epn.
> The number of SVs before and after executing my code stays the same (or
> decreases!). BUT the number of SVs between invocations when called by
> mini_epn increases. Below is an example where I use Devel::Leak and have
> changed the output of my service check to be the ENTER and LEAVE values
> returned by NoteSV and CheckSV (note that the first invocation increases
> dramatically because of DynaLoaded modules)
>

I am the author of mini_epn and am too aware (now that I have started 
trying to code XS's) of how ignorantly it was coded.

Bear in mind that mini_epn is only a means of assessing whether or not a
plugin will __run__ under an ePN (if it fails mini_epn, it will
certainly fail ePN. If it passes however, it may still fail to run under
ePN. There exist modules for example that will run once in mini_epn but 
not more than once).

I will try and re-examine it and see if there are any faults that I can 
see.

However, if there are faults in mini_epn, there are almost certainly 
faults in ePN since mini_epn is the guts of ePN (from base/checks.c) 
stuck in a loop.

Please fix them and it as best you may. 

The ePN stuff is _all_ contributed. The developer, Stephen Davies, (I
will write you offline with his address) is acknowledged in the code (eg
common/config.h.in) and in the docs.

Although Mr Galstad says he only includes contributions that he 
understands and meet a need, this one may have slipped by.
 
> $ ./mini_epn 2>/dev/null
> Enter file name: check_remote_interfaces-leak_test
> embedded perl plugin output was -12820724,ENTER: 32488 LEAVE:32674
> 
> Enter file name: check_remote_interfaces-leak_test
> embedded perl plugin output was -12820724,ENTER: 32686 LEAVE:32686
> 
> Enter file name: check_remote_interfaces-leak_test
> embedded perl plugin output was -12820724,ENTER: 32694 LEAVE:32693
> 
> Enter file name: check_remote_interfaces-leak_test
> embedded perl plugin output was -12820724,ENTER: 32701 LEAVE:32700
> 
> Enter file name: check_remote_interfaces-leak_test
> embedded perl plugin output was -12820724,ENTER: 32708 LEAVE:32707
> 
> > You could also run any suggestions past the ePN author (noted in the
> > source).
> 
> I couldn't find this person's info (is it not Ethan Galstad?).
> I don't want to bother who are no longer involved in the project.
> 

He can choose whether he wants to reply or not. As you are aobviously 
interested and able to contribute to this stuff, I am sure he will 
welcome it.

Yours sincerely.
-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en




More information about the Users mailing list