[nos-bbs] Generic malloc failure -- why?

[(Skip) K8RRA]

Hi Maiko!  Thanks for thinking about this.

On Sun, 2007-09-09 at 05:44 -0500, Maiko Langelaar (ve4klm) wrote:
> Hi Skip,
> 
> > No space!!
> 
> Then JNOS shutdowns down right ?
Nope - it remains running and generates a string of messages, one per
line exactly as formatted, I don't know on what frequency...
> 
> > Thus far I can't tie the message to any particular event.
> 
> JNOS is asking for memory from linux, and linux says no.
Yup, I got that far in the analysis - I am looking for an external event
but am still without joy.  Could a stray APRS request [I have not
enables APRS but have applied one workaround in the autoexec] show up
this way?

I can say this about memory availability:
 1) real memory [512mb] is shown fully used -- 3/4 code, 1/4 cached
 2) virtual mem [1.6gb] is shown partly used -- ~200mb avg, 500mb peak
 3) having 1.6gb swap violates a 512mb max rule [jnos is the only
casualty if this is the reason].
 4) when starting, jnos has the history of reporting memory available to
total real + swap + free space on / file system -- I've wondered if it
really was prepared to use the root file system as swap but I have taken
no steps to test the question...:-)

> 
> Where you running any TRACE sessions at the time ?
Nope - jnos has been too well behaved for the extra step.  If gdb is
needed for the analysis I'll start it up PDQ.
> 
> > Does this mean that other software is playing dirty?
> 
> Hard to say. Could be a rogue daemon using up all the
> system memory. Could be a DOS (denial of service) attach
> on your machine. Corrupt or fragmented memory could do
> it as well.
HMMM - DOS is unlikely, so is corrupt unlikely.  Fragmented might be
possible since re-boot is a once-per-month [give or take] thing for me.
Actually I'm surprised at fragmented as a reason, I would expect malloc
to be pretty aggressive at shifting stuff around to get space for a
request.  Could jnos be asking for an unusually large chunk that needed
to be in real space and not be swappable?
> 
> Google for 'malloc fail why' and you'll find various
> reasons for why the malloc() function call might fail.
I'll do this and continue more careful observation on a quicker
interval.  More(?) later...
> 
> Maiko
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de [George (Skip) VerDuin] K8RRA k