This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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