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)") 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
