20000912: "make nc_test/test" failure on Fujitsu VPP

Dear Dr. Bader,

>Date: Wed, 13 Sep 2000 17:16:20 +0200
>From: Reinhold Bader <address@hidden>
>Organization: Leibniz-Rechenzentrum Muenchen
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20000912: "make nctest/test" failure on Fujitsu VPP
>Keywords: 200009121427.e8CERNb20315

The above message contained the following:

> the "gmake test" issued in nc_test executes "nc_test -c"
> after compiling the executable; however it simply dumps core.

This is bad.  Correct testing of the version 3 API depends upon the
successful execution of the "nc_test -c" command to create an initial
netCDF file.

Unfortunately, we don't have access to a Fujitsu VPP, so we can't
investigate the problem.  If you're willing to help us, however, then we
should be able to diagnose the problem.

Initially, I'd like to know the exact cause of the crash and see a dump
of the calling stack.  This requires that the netCDF package be compiled
with debugging enabled.  If it wasn't compiled that way, then please do
the following:

    1.  Go to the top-level source directory.

    2.  Perform steps 3 through 5 near the end of the INSTALL file.

    3.  Ensure that the environment variables FC and CXX are set to the
        empty string (we don't need the Fortran and C++ interfaces to
        diagnose the problem).

    4.  Ensure that the environment variable CFLAGS contains whatever
        option is necessary in order to enable debugging.  Also, ensure
        that any optimization options are consistent with debugging.

    5.  Perform steps 6 through 7 near the end of the INSTALL file.

You should then perform a trivial check of the netCDF library by going
into the "libsrc/" subdirectory and executing the command "make test".
It should succeed because it did before.

When ready, go into the "nc_test/" subdirectory and do the following:

    1.  Execute the command "make" to create the "nc_test" program.

    2.  Execute the command "./nc_test -c" under control of a debugger.

    3.  Send me information on the cause of the crash and a dump of the
        calling stack.

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