Remaining memory leaks

[Alex Kiernan]

Alex Kiernan <alexk at demon.net> writes:

> Alex Kiernan <alexk at demon.net> writes:
> 
> > This is the last one I had left over from the last debugging session:
> > 
> > New memory leaked: 331008 bytes (2.91%); potentially leaked: 0 bytes (0%)
> > 
> > MLK: 331008 bytes leaked at 0x1890048
> >   * This memory was allocated from:
> > 	malloc         [rtlib.o]
> > 	realloc        [rtlib.o]
> > 	x_realloc      [xmalloc.c:108]
> > 	BUFFappend     [chan.c:74]
> > 	NClist         [nc.c:612]
> > 	NCproc         [nc.c:844]
> > 
> > I'm going to try removing the tests against "cp->{In,Out}.size >
> > BIG_BUFFER" at the tail end of CHANclose to see if thats how they're
> > getting leaked (since there's places other than the main channel table
> > which do "CHANclose(p); p = NULL;" kind of stuff).
> > 
> 
> Ignore this, I think it really is a phantom... I'm checking some more.
> 

Definately a phantom... 16 hours of uptime, 0 leaked bytes!

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC