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.
>From: Gilbert Sebenste <address@hidden> >Organization: NIU >Keywords: 200210050242.g952g0127088 McIDAS-XCD DMRAOB DMSYN Gilbert, Earlier today I sent you an email to let you know that I found what could be a huge memory leak in a routine used by all of the McIDAS-XCD data monitors (e.g., dmsfc.k, dmraob.k, dmmisc.k, and dmsyn.k). (This email man not have gotten to you as our mail server was under a denial of service attack from FTP and web services.) I made modifications to the file, stnqry.c, last night on weather2 and rebuilt and installed all of the data monitors. When I logged onto weather this morning, all of the data monitors were running nicely. By the time I got into work, dmsyn.k had once again hit the wall using as much CPU as it could. This time, however, I did notice the size of the routine when it was using up the CPU and could compare it with the size just after startup: size on startup: 1028 KB size when stuck: 3228 KB So, it looks like there is an additional memory leak/several memor leaks that are still affecting dmsyn.k. I will be trying to find and fix those each time I see dmsyn.k hit the wall. The interesting thing is that the routine that gets into the infinite loop is located in a system library. The routine is attempting to identify enough memory to allow a malloc to succeed. This is a new and apparently associated with gcc 3.2. The root cause of the problem, however, it seems is with McIDAS code. Tom