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.
> Daryl, > > I'll have to take a look at this. The NCWD is the largest grid > being decoded at the moment (almost). Its 1.6 million points > and will grow the malloc'd space , so I'll pass things through valgrind > too watch the memory use. The 1/12 degree SST is 9 million > points which can really look big in memory as well. > > Steve Chiswell > Unidata User Support > Daryl, I have tracked down the memory leak related to the bit masked grids such as the NCWD grid. The problem was a missing static declaration for the pointer and size so that each time the bit mask was realloc'd, it was creating a new block. I have a source code fix, or can post a binary of just the dcgrib2 decoder for the 5.10.4 distribution, whichever you would like. Steve Chiswell Unidata User Support > > > > Hi, > > > > I've been noticing a dcgrib memory leak while decoding this: > > > > HDS ^[YZ]..... KKCI.*/mAWC_NCWD > > PIPE dcgrib2 -d data/gempak/logs/dcgrib2_AWC_NCWD.log > > -e GEMTBL=/home/ldm/nawips/gempak/tables > > data/gempak/model/awc/YYYYMMDD_ncwd.gem > > > > I'm rolling with 5.10.3 UPC binaries x86_64 Linux on RHEL5. > > > > Here is snapshots of the process in the last 10 minutes > > > > ldm 11410 0.1 0.4 53000 16260 ? S 17:38 0:00 dcgrib2 > > > > ldm 11410 0.0 0.7 72696 30204 ? S 17:38 0:00 dcgrib2 > > > > ldm 11410 0.0 0.9 79256 36768 ? S 17:38 0:00 dcgrib2 > > > > It grew to 8 GB in just under 2 days :( > > > > Nothing special in the log file. > > > > thanks! > > daryl > > > > > Ticket Details =================== Ticket ID: BRA-222690 Department: Support GEMPAK Priority: Normal Status: Closed