[Rd] R on Solaris 10 x64

[Peter Dalgaard]

Greg Nakhimovsky wrote:
> Peter,
>
> Thanks for the hints.
>
>> 2 things caught my eye (except that their "R code" is clearly C): The 
>> dbx output doesn't show off[curr_seq], which could actually be the 
>> culprit, 
>
> (dbx) p off[curr_seq]
> off[curr_seq] = 0
>
>> and the _memcpy call on the stack looks odd:
>>
>> _memcpy(0x0, 0xfdebc707, 0x9f5c4f0)
>
> It shows the register values, which are not necessarily the arguments 
> to memcpy(), apparently not in this case.
>
> The "guilty" line of code
>
> HDmemcpy(tgath_buf,buf+off[curr_seq],curr_len);
>
> translates into (due to macro "#define HDmemcpy(X,Y,Z) 
> memcpy((char*)(X),(const char*)(Y),Z)")
Hmm, and can you see "both ends" of tgath_buf and buf (in particular 
tgath_but[curr_len - 1] and buf[curr_len-1])?

If only to "eliminate from our inquiries", I'd try running CPP over the 
code and see if the full macro expansion (including that from memcpy to 
_memcpy) is working as intended.

I take it that you've already tried compiling the module at maximal 
warning level?

>
> memcpy((char*)(tgath_buf),(const char*)(buf+off[curr_seq]),curr_len);
>
> and
>
> (dbx) p tgath_buf
> tgath_buf = 0x9f5c4f0
> (definitely not NULL)
>
> We've also asked for help at help at hdfgroup.org regarding the HDF5 
> package.
>
> This is under Solaris 10 x86, using the latest Sun Studio compiler/tools.
>
> -Greg
>
>>
>>
>> (What happened to the length and how did NULL get in there.) If 
>> memcpy() is a macro, I think I'd take a closer look at the include 
>> files and see if something is getting expanded in an unintended way.