[Rd] R on Solaris 10 x64
p.dalgaard at biostat.ku.dk
Fri Apr 13 23:40:16 CEST 2007
Greg Nakhimovsky wrote:
> 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
> (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
> 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
> memcpy((char*)(tgath_buf),(const char*)(buf+off[curr_seq]),curr_len);
> (dbx) p tgath_buf
> tgath_buf = 0x9f5c4f0
> (definitely not NULL)
> We've also asked for help at help at hdfgroup.org regarding the HDF5
> This is under Solaris 10 x86, using the latest Sun Studio compiler/tools.
>> (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.
More information about the R-devel