20021125: DMSYN takes over CPU (cont.)

>From: Robert Mullenax <address@hidden>
>Organization: Universal Weather
>Keywords: 200211251502.gAPF2r404684 McIDAS-XCD DMSYN

Robert,

re: dmsyn problem on RH 8.0 Linux

I think that the problem I am seeing on Gilbert's system is more of a
GCC 3.2 problem than a RH 8.0 one -- if they can be separated.  What
happens is that the dmsyn.k executable in memory grows slowly which for
the most part is no big deal.  When a new day's MD file is created,
however, the size more than doubles.  At some point right after that,
dmsyn.k is no longer able to malloc more memory.  This is very weird
given that the memory image is not really all that big (around 3 MB).
I still do not understand the reason for the growth -- and I have read
code until my eyes blurred.  While looking for the problem, however, I
found lots of places in code related to querying of the station
databases that have actual and potential memory leaks.  After fixing
the majority of these leaks (I won't say all 'cause I keep finding
them), the dmsyn.k executable continues to run after its growth.
Interestingly, if it runs long enough (say a half hour), its size (as
listed by 'top') drops back down to close to what it was before the
growth.  This is the part I don't understand because I think I got rid
of the memory leaks that could be happening.  Also, I ask myself _why_
the size drops back down after awhile!?

re: McIDAS problems
>As far as McIDAS goes except for the GMS imagery thing I have had no
>problems at all, either.

And I will be looking into the GMS problem today.

re: McIDAS is hard to configure
>I find it easy but I have bene doing it for nine years.  It is certainly
>better than the SSEC way.  For any reasonably competent admin, your config
>is not hard.  

I have been thinking about creating a Tcl/Tk GUI that can be used to
finish the setup and configuration for 'mcidas'.  One of these
weekends, I will dive into this development.  My problem is that I
simply don't have time for new, fun stuff given the amount of bugs that
are still waiting to be fixed.  The biggest of the outstanding bugs is
the inability of Linux to serve sounding data through 'vpserv'.  Dave
Santek had a slide at the MUG meeting that suggested that they had new
code that appears to fix the problem, but my testing of that code shows
that it doesn't.

re: trce file gets created by IMGREMAP

>Hey, I was just going to ask you about that!  I had to write a script
>that goes in and removed that file every so often..I went in and found
>one that was like 300MB one day..Thanks!

Here is what to do:

<as 'mcidas'>
cd mcidas2002/src

edit imgremap.pgm and remove the following lines:

c --- add TRACE=1
      ndirsorts = ndirsorts + 1
      dirsorts(ndirsorts) = 'TRACE=1'

and then rebuild and reinstall imgremap.k:

make imgremap.k
rm ~/bin/imgremap.k
ln imgremap.k ~/bin

The imgremap.pgm fix will be in my next addendum.

Later...

Tom

>From address@hidden Mon Nov 25 10:06:52 2002
>Subject: RE: 20021125: DMSYN takes over CPU (cont.) 

Thanks, I'll make that imgremap fix.

That GMS thing is very weird as it seems there are varying levels
of brokeness depending on the machine.

I noticed Sun brought back compilers for Solaris Intel, but still
didn't bring back the FORTRAN compiler.  I am trying to make the Linux
switch but we have had serious NFS problems that our Linux admin
says is a known bug that the kernel developers are working on.

I still have plans to investigate FreeBSD..one thing I need to check on
is to see if there is a FreeBSD driver for the Intel Gigabit Ethernet.