>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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.