From jeff.hamann at forestinformatics.com  Tue Nov 30 17:01:14 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Tue Nov 30 17:01:37 2004
Subject: [Rd] data is getting corrupted
In-Reply-To: <38nnq0lmi3v96aqov831lln4mkn3bt11ud@4ax.com>
References: <1131.128.193.136.240.1101749262.squirrel@www.forestinformatics.com> 
	<38nnq0lmi3v96aqov831lln4mkn3bt11ud@4ax.com>
Message-ID: <1083.128.193.136.240.1101830474.squirrel@www.forestinformatics.com>

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

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

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@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
>


-- 
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon 97339-1421
phone 541-754-1428
fax 541-752-0288
jeff.hamann@forestinformatics.com
http://www.forestinformatics.com


[Rd] data is getting corrupted
Jeff D. Hamann