[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

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