R on Solaris 10 x64
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.