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 [EMAIL PROTECTED] 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. ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
