[Rd] data is getting corrupted

[Duncan Murdoch]

On Tue, 30 Nov 2004 08:01:14 -0800 (PST), "Jeff D. Hamann"
<jeff.hamann at forestinformatics.com> wrote :

>I'm not sure I described the problem correctly with my last post.

Or maybe I missed that.  Sorry!

>The structure that is being allocated contains fixed length arrays and
>thus, the location of the strings aren't NULL (the contents are however).

I'd suggest using strncpy instead of strcpy; it might be that one of
your strings is longer than expected, and is overwriting something it
shouldn't.

Duncan Murdoch
>
>struct SAMPLE_RECORD
>{
>char            forest[HEADER_CHAR_STR];       /*  forest identifier    */
>char            subunit[HEADER_CHAR_STR];      /*  subunit              */
>char            stand_name[HEADER_CHAR_STR];   /*  stand name           */
>char            legal[HEADER_CHAR_STR];        /*  legal description    */
>long            elevation;                     /*  elevation (ft)       */
>double          acreage;                       /*  number of acres      */
>unsigned long   age;                           /*  stand age            */
>
>unsigned long   sampled_month;     /*  month of the year    */
>unsigned long   sampled_day;       /*  day of the month     */
>unsigned long   sampled_year;      /*  year measured        */
>unsigned long   current_year;      /*  year of forecast     */
>
>double x0;
>
>unsigned long           n_points;
>struct PLOT_RECORD      *plots_ptr;
>
>unsigned long           n_plants;
>struct PLANT_RECORD     *plants_ptr;
>};
>
>The plots_ptr and plants_ptr are set to NULL because they're not static
>arrays and are allocated.
>
>Since the problem didn't manifest itself within the strings, but rather in
>the arrays that are allocated (plants_ptr) and specifically a single
>column (variable) that occurs within the plants_ptr, I still think I have
>a problem with the PROTECT/UNPROTECT operations because with small
>data.frames (200 rows x 10 cols) the code works fine. With larger
>data.frames (2000 rows x 10 cols), then the corruption begins. COuld this
>be a problem with the sequencing of the allocate
>plants_ptr->PROTECT->assign values to variables->UNPROTECT? Is it possible
>to find out when R is performing garbage collection or moving data around?
>
>Thanks,
>Jeff.
>
>
>Duncan Murdoch said:
>> On Mon, 29 Nov 2004 09:27:42 -0800 (PST), "Jeff D. Hamann"
>> <jeff.hamann at forestinformatics.com> wrote:
>>
>>>/* this function converts the sample list	*/
>>>/* from R into the internal structure		*/
>>>struct SAMPLE_RECORD *build_sample_from_sexp( SEXP sample )
>>>{
>>
>> [ declarations deleted ]
>>
>>>
>>>   char                    temp_sp_code[16];
>>>   struct SAMPLE_RECORD *s_ptr;
>>>   struct SPECIES_RECORD *sp_ptr;
>>>
>>>   s_ptr = (struct SAMPLE_RECORD *)calloc( 1, sizeof( struct
>>> SAMPLE_RECORD
>>>) );
>>
>> This allocates a structure, initialized to all zeros.
>>
>>>/*    s_ptr = (struct SAMPLE_RECORD *)Calloc( 1,  struct SAMPLE_RECORD );
>>> */
>>>
>>>   /* *fill in the header info */
>>>   strcpy( s_ptr->forest,
>>>CHAR(STRING_ELT(get_list_element(sample,"forest"), 0)) ) ;
>>
>> This copies the string element to the address s_ptr->forest points to,
>> which is address 0, since you didn't change it from the initial NULL.
>> I'm surprised you didn't get a bigger error than the one you saw.
>>
>> [ more deletions ]
>>
>>>I'm sure there's something I don't understand about the PROTECT/UNPROTECT
>>>sequence as this seems to work on smaller data.frames
>>
>> Maybe you were just lucky that the overwriting at address 0 didn't
>> trash anything in those cases?
>>
>> Duncan Murdoch
>>