[GEMPAK #VTP-245146]: Bus error with binary darwin nmap2 - 5.9.2.

> Thanks Steve!
> 
> Do you know if there is something I can do to fix the Darwin Xorg vs.
> XFree86 issue? (assuming that is why the 5.9.2 base crashes nmap2).
> Let's back up a second - what do you do to set up an environment for
> compiling GEMPAK on darwin?  I could replicate on mine, and just use
> the source . . .
> 
> Stonie

Stonie,

I believe the problem you are having with the L2 data stopping its updating 
after a period of time is primarily due to a file descriptor leak
which I have now fixed. The memory leak (which I also have fixed) would
likely take quite some time to be a problem (and only under certain null
sweep products), whereas running out of FD's will happen in all cases.

As for building under Mac OSX, its problematic due to the fact that Apple
gcc environment does not have fortran support. You need to install a
consistent gcc/g77 environment (either fink which we have done, opendarwin, or 
build 
and install your own- which is what I did on one machine). We are still trying 
to come up with
a baseline configuration cookbook for an environment that will support GEMPAK, 
McIDAS,
and other packages. The headaches with openmotif and X11 occur due to
shareable gcc library versions (4.0.0 and 4.0.1).

Since you are able to run the 5.9.2 executable, the other problem may be in 
reading a table
somewhere on your system (see if your GEMTBL is correct for 5.9.2, or if
you have made local mods to datatype.tbl etc.

I'll repost the binaries in a few hours.

Steve Chiswell
Unidata User Support 


> 
> On Jun 7, 2006, at 1:32 PM, Unidata GEMPAK Support wrote:
> 
> >> Only when setting up with L2 data (I tried this with satellite and L3
> >> data); when left on autoupdate, the data will "lose it's source"
> >> after running for a few hours. The L2 data will stop updating, and
> >> if I go to the data selector, the menus will look as if I have no
> >> data below the $RAD or $SAT level. It I exit and then bring it back
> >> up, it's fine - and sees the current data.
> >
> > Stonie,
> >
> > I believe this is a memory leak issue in the rsl library. I found
> > one that will
> > lose 3200 bytes every time a sweep is encountered with no radials. On
> > a test file yesterday, I observed 12,800 byes lost every time the
> > file was read.
> > That may be a problem over a loop that runs for a while, but can't
> > say how long
> > it would be before OSX started to have trouble.
> >
> > At any rate, I'm fixing that up now.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> > Ticket Details
> > ===================
> > Ticket ID: VTP-245146
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Closed
> >
> 
> 


Ticket Details
===================
Ticket ID: VTP-245146
Department: Support GEMPAK
Priority: Normal
Status: Closed