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

From: Hin-Tak Leung <hin-tak.leung_at_cimr.cam.ac.uk>
Date: Fri 05 Jan 2007 - 19:51:12 GMT

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).


R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat Jan 06 11:22:41 2007

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Sat 06 Jan 2007 - 00:31:06 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.