[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20020918: NMAP2 memory issue.

Steve,

Working with the final release of 5.6.h, I have done more testing . . . and I 
believe I have located the logic issue - just not the offending code, yet.

To replicate, kick up NMAP2 in a 16 or 24 bit X session, bring up a satellite 
or radar loop . . . and make sure auto-update is enabled.

Then watch the memory tick up with each update - under the X process, though, 
not nmap2.  It takes more than a day for it to become a real issue in 16bit - 
faster if you run in 24bit.

The symptom appears to point to a failure to free or reuse the memory used 
for the replaced frame . . . i.e. each update does a new allocate for memory 
for the new frame, but the head frame, which leaves the loop, still holds 
it's memory.  If this is, indeed, the problem - the code should be repaired 
to either reuse the head frame's memory for the new frame, or do a free on 
the head frame when doing an allocate on the new.

I apologize for not supplying more info or tracking down the code myself, but 
my family would kill me if I didn't pack for our vacation.

Stonie

On Wednesday 18 September 2002 15:09, Steve Chiswell wrote:
> Stonie,
>
> The gn driver (used by gdradr to display the radar data) had a memory leak
> previously that I fixed with the 5.6.h distribution on Monday (the crnexz.c
> routine caling zlib could exit with memory still allocated to the zlib
> inflater).
>
> Each nmap2 session (again would be affected by the gn bug previously)
> has up to 8 loop windows....I haven't noticed a problem here, but
> I can run it out of memory if I have a bunch of really long loops
> (eg 50 radar images in loop1, more in loop2 etc.).
>
> Just to double check....did you download the new 5.6.h distribution or
> is this the ppreview release you are using?
>
> Steve
-- 
Stonie R. Cooper
Planetary Data, Incorporated
ph. (402) 782-6611