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

20021110: dmraob.k and dmsyn.k hanging on weather2 (cont.)

>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200210050242.g952g0127088 McIDAS-XCD DMRAOB DMSYN


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.


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.