960930: nctest segmentation violation (signal 11) in libsrc/xdrffio.c

Bob,

>Date: Tue, 1 Oct 1996 17:05:42 -0400 
>From: "Bob Swanson" <address@hidden>
>Organization: Lockheed Martin Technical Services
>To: Steve Emmerson <address@hidden>
>Subject: Re: 960930: nctest segmentation violation (signal 11) in 
>libsrc/xdrffio.c 
>Keywords: 199610010325.AA14947

In the above message you wrote:

> It calls some other routines, such as strerror, and fprintf. 
> This may not be as big an issue as I am implying, but my
> experience with the Cray software, is that when a job runs out
> of memory, it is very difficult to issue error messages
> using "fprintf(stderr,"etc"" . Many of our users are NQS
> users, and the newer versions of netCDF use a lot more
> memory. Thus, they may hit their limit more easily.
> 
> The real problem is not precisely associated with memory, but
> is the fact that strerror does not issue any error messages
> associated with FFIO. Try the program:
> 
> #include <string.h>
>  
> main()
> {
>         printf("error %d = %s\n",17,strerror(17));
>         printf("error %d = %s\n",5001,strerror(5001));
> }
> 
> Error 17 (which tripped up my first cut at this error processing)
> is clearly documented by the call. However, the error
> 5001, which is a FFIO open error, is not processed by
> strerror. It passes an empty string.
> 
> I'm working on some code right now that handles errors of
> both the system error type (strerror stuff), and
> FFIO open errors. Anything else will have to be written
> to stderror as a decimal error number. The user should
> be able to enter "explain lib-???" where ??? is the decimal
> number I write. Unfortunately, I am finding out that there are 
> too many different kinds of errors that can come from an 
> "ffopen" call.
> 
> This work is important due to our site's heavy use of
> netCDF, so I have a good sized stake in this matter.
> 
> Hope this helps explain some of my slightly rabid behavior.
> I hope we can find some decent solution for this self-induced
> problem.

Be advised that, in order to be acceptable by us, any solution you
create will have to work on a variety of UNICOS system (e.g. PVP, MPP)
and be backward as well as forward compatible.  Good luck.

--------
Steve Emmerson   <address@hidden>