970918: DEC Alpha, Linux, and netCDF-3.3.1 - floating point exception

Scott,

>Date: Wed, 17 Sep 1997 16:23:40 -0600 
>From: "Scott R. Wilson" <address@hidden>
>Organization: Bio-Rad Semiconductor Division, CD Systems
>To: address@hidden,
>To: address@hidden
>Subject: Re: 970917: DEC Alpha, Linux, and netCDF-3.3.1 - floating point 
exception
>Keywords: 199709162327.RAA11816

In the above message, you wrote:

> Looks like bad news. There is no signal.h in /usr/include/bsd on the
> RH4.2 Alpha. There is on my Slackware'96 Intel Linux boxes, but not on
> the Alpha.

My suggestion was based on the signal(2) manual page on our Linux 586
system.  It mentioned that signal handling was reset to the default
(i.e. abnormally terminate the program) after a signal was delivered
(which is non-standard behavior) unless <bsd/signal.h> was included.  Oh
well, it was worth a try.

> 
> I did try adding a compile flag -D__USE_BSD, -D_USE_BSD, -D__USE_BSD_SIGNAL,
> -D_USE_BSD_SIGNAL and then re-making everything in nc_test, but I got 
> identical results to those I got before (FPE). Also tried -D_GNU_SOURCE. Same
> effect.
> 
> I also tried including <unistd.h> but it also had no effect.
> 
> I found only two files in /usr/include/bsd: bsd.h and tzfile.h. bsd.h is 
> included below, and after that is signal.h from /usr/include.
> 
> Let me know what else I can do... would it be helpful for you to
> be able to play with this box directly? I can arrange (I think) for a
> login for that purpose. The box is actually in England, but I work on it
> all the time from Albuquerque via the net.

I'm afraid we don't have any clients (people in Atmospheric Science
departments) who use an Alpha/Linux system; consequently, your problem,
while interesting, isn't a priority.  You can go ahead with getting me a
login, but I can't promise I'll be able to work on it.

Since the problem appears to be the non-standard behavior of the
signal() call, you might try modifying the code so that a floating-point
exception handler is actually installed (rather than just setting the
behavior to SIG_IGN).  The first thing the handler should do is to
re-establish itself as the SIGFPE handler or (alternatively) cause
SIGFPE to be blocked.

> Many thanks for your help,
> Scott Wilson
> address@hidden

Let me know what you decide/discover.

Just FYI, Linux also has non-standard behavior in the malloc() function:
it *always* returns successfully -- no matter how much you allocate and
regardless of whether or not accessing the allocated space will
cause a SIGSEGV.

--------
Steve Emmerson   <http://www.unidata.ucar.edu>