[Rd] R on Solaris 10 x64

Greg Nakhimovsky Greg.Nakhimovsky at Sun.COM
Sat Apr 14 00:01:29 CEST 2007

> Hmm, and can you see "both ends" of tgath_buf and buf (in particular 
> tgath_but[curr_len - 1] and buf[curr_len-1])?

(dbx) p tgath_buf[curr_len - 1]
tgath_buf[curr_len-1] = '\0'
(dbx) p buf[curr_len-1]
dbx: cannot access address 0x9f7f6ff
(dbx) p tgath_buf[curr_len - 2]
tgath_buf[curr_len-2] = '\0'
(dbx) p buf[curr_len-2]
dbx: cannot access address 0x9f7f6fe

Something is definitely wrong with this memcpy() operation. I 
suppose we'll need some help from the HDF5 folks to figure out 
what the buf memory buffer is supposed contain in this case.

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

After the macro expansion, this code looks like this:

         for(curr_seq=0; curr_seq<nseq; curr_seq++) {
              memcpy ( ( char * ) ( tgath_buf ) , ( const char * 
) ( buf + off [curr_seq ] ) , curr_len );
> I take it that you've already tried compiling the module at maximal 
> warning level?

No. We can try that, as well as lint.



More information about the R-devel mailing list