This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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>