[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

960206: netCDF on BSD

Masato,

>Date: Tue, 6 Feb 96 19:35:01 JST 
>From: address@hidden (Masato Shiotani)
>Organization: Div. of Ocean and Atmospheric Sci., Hokkaido Univ.
>Subject: Re: 960205: netCDF on BSD 
>Keywords: 199602010918.AA01928

In the above message you wrote:

> >>     4.  Execute the command `make'.  Trap the output and send it to me.
> 
> The following is output.
> 
> # make
> ./fortc -L . -O bsd_f2c common.inc > netcdf.inc
> m4: -: cannot open for input.
> ./fortc -L . -O bsd_f2c jackets.src > jackets.c
> m4: -: cannot open for input.

The above error messages from the m4(1) utility are not good.  They
indicate that the utility is broken (I've seen this error before from
the UNICOS m4(1) utility).  I will send you the files `netcdf.inc' and
`jackets.c' in separate messages.  Put them in the fortran/ subdirectory
and execute the command `make'.

> >> I'm sorry.  I should have said that the XDR library would need to be
> >> recompiled with the `-g' (debug) option.  Would you please do the
> >> following:
> >> 
> >>     1.  Go to the xdr/ subdirectory.
> >> 
> >>     2.  Edit the file `Makefile': change the value of the CFLAGS macro
> >>    from `-O' to `-g'.
> >> 
> >>     3.  Execute the command `make clean'.
> >> 
> >>     4.  Execute the command `make'.  Trap the output and send it to me.
> 
> 'Make' did nothing here.  So I go up src/ directory and 'make' again
> with a change in Makefile in xdr/ subdirectory as you indicated.

Did you execute the command `make clean'?  Judging from the debugger 
output, it appears that the files in the xdr/ subdirectory were not
compiled with the `-g' option (the argument lists do not have variable
name information).  Would you please do the following:

    1.  Go to the xdr/ subdirectory.

    2.  Execute the command `make clean'.  Trap the output and send it
        to me.

    3.  Execute the command `make all test'.  Trap the output and send
        it to me.

<snip>

> >>     7.  Manually invoke the debugger on `xdrtest' as you did before.
> >>    Run the program and dump the contents of the call stack when the
> >>    memory fault occurs.  Send the output to me.
> 
> The output from 'gdb' is also similar to that I sent you before.
> 
> # gdb xdrtest
> (gdb) run
> Starting program: /usr/local/src/netcdf-2.4-beta6/src/xdr/xdrtest 
> string: Hiya sailor. New in town?
> unsigned bytes: 254 255 0 1 2 0 0 0 
> ints: 5 6 7 8 9 
> unsigned ints: 65535 65534 0 1 2 
> LONG: 82555
> longs: -4 -3 -2 -1 0 
> unsigned longs: 65535 65534 0 1 2 
> floats:
>          1.001250e+02
>          1.002500e+02
>          1.003750e+02
>          1.005000e+02
>          1.006250e+02
> 
> 
> Program received signal 11, Segmentation fault
> 0x9a83 in memcpy (0x00000001, 0x00000004, 0x00000001, 0x0000bb7c)
> (gdb) where
> #0  0x9a83 in memcpy (0x00000001, 0x00000004, 0x00000001, 0x0000bb7c)
> #1  0xbb7c in edata (0x00000001, 0x00000004, 0x00000001, 0x0000bb7c)
> #2  0x33bb in xdrstdio_create (0xefbfdb14, 0x00000001, 0x00000000, 0xefbfda10)
> #3  0x356c in xdr_double (0xefbfdb14, 0xefbfda10, 0xffffffff, 0x0000347c)
> #4  0x3695 in xdr_vector (0xefbfdb14, 0xefbfda10, 0x00000005, 0x00000008)
> #5  0x2fdb in main (ac=1, av=0xefbfdb5c) at xdrtest.c:353
> 
> Are we getting stuck?

Not yet.  This process must take time because we are working on opposite
side of the planet.  Patience is the important thing.

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