NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
I can confirm James' observations. The problem looks like it may be difficult
to trace ... I can get the program to abort at line 812 in
$GEMPAK/source/programs/gui/nmap2/nmap_spfw.c:
if( ! (spftext = XtMalloc((Cardinal)flen))) {
However, inserting some printf statements, as well as some other innocuous code
changes, cause the error to appear further along in the code ... which likely
means that the actual error lies elsewhere. Since the Abort error often is
tied to a stack violation on OSX, I tried recompiling with the
-fno-stack-protector option, which corrects NMAP2 aborts on Ubuntu, but this
did not help. I suspect that there is some insidious buffer overflow hiding in
the NMAP2 code base. Maybe compiling with -Wall may turn up something.
In the meantime, James, you can still load your .spf files in NMAP2 on OSX by
using the command line option to load spf files ... e.g., "nmap2 -as
sample.spf".
I also can confirm the problem with loading vg files on OSX.
Cheers,
Kevin
_____________________________________________
Kevin Tyle, Systems Administrator
Dept. of Atmospheric & Environmental Sciences
University at Albany
Earth Science 235, 1400 Washington Avenue
Albany, NY 12222
Email: ktyle@xxxxxxxxxx
Phone: 518-442-4578
_____________________________________________
-----Original Message-----
From: gembud-bounces@xxxxxxxxxxxxxxxx [mailto:gembud-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Stonie R. Cooper
Sent: Wednesday, August 14, 2013 7:52 PM
To: James Murakami
Cc: Unidata gembud
Subject: Re: [gembud] Nmap2 problem on Mac OS X 10.6.8
Shoot. That is ugly. I don't even have access to a modern Mac OS to try to
debug. You would need to use a debugger with the "-g" flag at compile time, or
add some stdout code with fflush() calls to try to find the issue.
On 08/14/2013 11:54 AM, James Murakami wrote:
> Hi Stonie,
>
> Thanks for the suggestion, but that didn't help. I edited
> $GEMTBL/nmap/spf.nmap and created a test directory for the ~/Documents
> folder. However, Nmap2 still crashed upon trying to restore the test
> setting(tried all sorts of variations).
> I tried running Gempak under bash(I'm a tcsh user by default), but the
> results were the same.
>
> James
>
> ----------------------------------------------
> James Murakami
> Staff Meteorologist/Student Affairs
> Department of Atmospheric and Oceanic Sciences University of
> California, Los Angeles
> 405 Hilgard Ave.
> Los Angeles, CA 90095-1565
>
>
> e-mail: tenki@xxxxxxxxxxxxxx
> telephone: 310-825-2418
> Fax: 310-206-5219
> ----------------------------------------------
>
> On 08/13/2013 04:51 PM, Stonie R. Cooper wrote:
>> James - when I had last played with this, the issue was pathing.
>>
>> But this was pre 10.6.x - so I am only guessing.
>>
>> When I saved a data setting, it stored it local to the path from
>> which I ran the nmap2 session, usually just my home directory.
>>
>> But the Mac OS bash shell always wanted to read it from ~/Documents.
>>
>> See if that helps.
>>
>> Stonie
>>
>> On 08/13/2013 05:24 PM, James Murakami wrote:
>>> Hi,
>>>
>>> I recently compiled GEMPAK 6.8.0 on a mini-Mac(OS X version 10.6.8).
>>> It seemed to compile fine, but one problem I ran into regards one
>>> functionality of Nmap2. The "Restore Data Settings" button(within
>>> the Data Selection Window) doesn't work. I created a map with radar
>>> imagery and surface observations superimposed. I clicked on the
>>> "Save Data Settings" button. Later, when I tried to bring up the
>>> same setting, the program crashes. This doesn't occur with Gempak on
>>> my Linux(CentOS) machine. Another quirk I found is that Nmap2 nor
>>> the program, gpmap, will plot a vgf file(only the map background
>>> shows up). Again, it's not a problem on my Linux machine(using the same
>>> data files).
>>>
>>> Have others noticed these problems, and is there a solution for it?
>>> The reason I'm using a Mac in this case it that it'll be a
>>> replacement for a Department display for the public. The current
>>> min-mac uses binary version of GEMPAK 5.11.1. I need to upgrade
>>> GEMPAK to be able to display gini satellite imagery(just copying the
>>> latest satellite configuration tables don't work for gini imagery).
>>> The closet space behind the display case is just large enough to
>>> accommodate a mini-mac.
>>>
>>> James
>>>
>> .
>>
>
>
_______________________________________________
gembud mailing list
gembud@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
gembud archives: