[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20030214: Problem with NF90_GET_ATT on an SGI
- Subject: Re: 20030214: Problem with NF90_GET_ATT on an SGI
- Date: Wed, 19 Feb 2003 15:57:07 -0700
>To: address@hidden
>From: Paul van Delst <address@hidden>
>Subject: Problem with NF90_GET_ATT on an SGI
>Organization: CIMSS@NOAA/NCEP/EMC
>Keywords: 200302141632.h1EGWK624961
Paul,
> I using the netCDF 3.5.0 F90 interface and I've discovered a problem with
> using the
> NF90_GET_ATT function to retrieve text attributes on an SGI platform. I use a
> call like
> so:
>
> NF90_Status = NF90_GET_ATT( NC_FileID, &
> NF90_GLOBAL, &
> HISTORY_GATTNAME, &
> History )
>
> where
> CHARACTER( * ), PRIVATE, PARAMETER :: HISTORY_GATTNAME = 'history'
>
> If the declared length of the argument "History" is smaller (say 256 chars)
> than the
> length of the attribute in the datafile (in my case 286chars), rather than
> the attribute
> being truncated, memory beyond the declared string is overwritten. The
> following is some
> output from my debug session where I put a trace on a main program variable
> "n" (a loop
> index) that was getting clobbered after a call to NF90_GET_ATT:
>
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [READ_SPCCOEFF_GATTS:896
> ,0x10071898]
> 896 NF90_Status = NF90_GET_ATT( NC_FileID, &
> (dbx) whatis history
> argument character*256 HISTORY
> (dbx) next
> [4] n changed before [memcpy: line 577]:
> old value = 1;
> new value = 808464943;
> Process 571314 (Combine_SpcCoeff) stopped on watchpoint writing address
> 0xffffff4c20 at
> [memcpy:577 ,0xda6111c]
> Source (of
> /xlv41/6.5.17m/work/irix/lib/libc/libc_64_M4/strings/bcopy.s) not
> available for Process 571314
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [memcpy:579 ,0xda61124]
> Source (of
> /xlv41/6.5.17m/work/irix/lib/libc/libc_64_M4/strings/bcopy.s) not
> available for Process 571314
>
> ...multiple numbers of these...
>
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [memcpy:614 ,0xda61234]
> Source (of
> /xlv41/6.5.17m/work/irix/lib/libc/libc_64_M4/strings/bcopy.s) not
> available for Process 571314
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4060
> ,0x10133310]
> 4060 *xpp = (void *)((char *)(*xpp) + nelems + rndup);
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4062
> ,0x10133320]
> 4062 return ENOERR;
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4060
> ,0x10133324]
> 4060 *xpp = (void *)((char *)(*xpp) + nelems + rndup);
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4062
> ,0x10133328]
> 4062 return ENOERR;
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4060
> ,0x1013332c]
> 4060 *xpp = (void *)((char *)(*xpp) + nelems + rndup);
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4062
> ,0x10133334]
> 4062 return ENOERR;
> (dbx) next
> Process 571314 (Combine_SpcCoeff) stopped at [NF90_GET_ATT_TEXT:76
> ,0x1008cbb0]
> 76 end function nf90_get_att_text
>
> The exact same code (and data file) works fine on an IBM AIX, Sun
> Sparcstation, and linux
> box - i.e. the too-long attribute is truncated with no side effects. I'm not
> sure if this
> is a problem on the SGI side (i.e. compiler problem) or the netCDF side
> (problem with how
> the ncx_pad_getn_text function works).
The function ncx_pad_getn_text() is part of the C interface. By the
time it gets the character string, there is no information available
about the space available for storing the attribute value. I'm afraid
the documented warning applies here:
... All elements of the vector of attribute values are returned, so
you must provide enough space to hold them. If you don't know how
much space to reserve, call NF90_Inquire_Att first to find out the
length of the attribute.
So the bottom line is that I don't think there is any practical way to
fix this problem, given the existing interface.
--Russ