[Rd] help for memory problem with 64-bit machines

[Hin-Tak Leung]

What Peter & Vladimir refers to are the causes of problems - adding 
"-Wall" to all of CFLAGS, CXXFLAGS, FFLAGS should spot some of them.
I did know of one case of uninitialised variable causing a crash -
doing "FILE *file; close(file);" crashes with gcc but not with sun 
workshop (sun workshop implicitly zeros uninitialise variables). There
is a gcc compiler switch (-fzero-uninitialized? or something,
read the manual) which does the same thing if you want to quickly check 
if the problem is due to uninitialised variables, but you better fix
*each* of the uninitialised variables anway.

Things to look out for in Peter's case are any explicit casts (which
are not a good idea, and also won't be picked up by -Wall because gcc
assumes that *you* are responsible for whatever you explicitly
asked for) e.g:
int a = (int) pointer_type;

The signed/unsigned comparion warning can be an overlap of the bit-width
difference Vladimir noted. A somewhat contrived example:

long a = 0xFFFFFFFF; /* = -1 in 32-bit, but a large number in 64-bit */
unsigned long b = 0;
if (a < b) {/* true in 32-bit, false in 64-bit */}

Peter Dalgaard wrote:
> Hin-Tak Leung wrote:
>> I got the same error with 64-bit R 2.4.1 on FC6 x86_64, and 32-bit
>> R 2.4.1 on the same machine is okay. There is definitely something wrong
>> with your code.
>>
>> I would suggest fixing all the compier warnings - there are piles of
>> them about uninitialized variables, and about doing comparison
>> between signed and unsigned expressions, etc first. Put -Wall in
>> CFLAGS CXXFLAGS and FFLAGS and you'll see.
>>
>> good luck.
>>
>> Hin-Tak Leung
>>
>>   
> Good advice. Also, the most common culprit for 64/32 problem is pointers
> stored as integers so watch out for any of those. And notice that you
> can set a breakpoint at randsk1_ and start poking around to see what is
> inside various variables and singlestep to the point of the crash (it's
> a bit painful and confusing in Fortran code, though.)
>> 
>> Also, the issue I most commonly see is the difference in size for "long" data 
>> type. On 32 bit sizeof(long)=sizeof(int)=32, but on 64bit sizeof(long)=64 
>> while sizeof(int)=32. 
>> 
>> This reverses a formerly safe practice of using long for 32 bit (and insuring 
>> the code compiles correctly on 16 bit machines).