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

Re: 20030214: Problem with NF90_GET_ATT on an SGI

>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