From Greg.Nakhimovsky at Sun.COM  Fri Apr 13 22:09:39 2007
From: Greg.Nakhimovsky at Sun.COM (Greg Nakhimovsky)
Date: Fri, 13 Apr 2007 16:09:39 -0400
Subject: [Rd] R on Solaris 10 x64
In-Reply-To: <461FDD59.8090408@biostat.ku.dk>
References: <461FBE20.4010901@sun.com>
	<Pine.LNX.4.64.0704131918480.695@gannet.stats.ox.ac.uk>
	<461FDD59.8090408@biostat.ku.dk>
Message-ID: <461FE383.70208@sun.com>

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



[Rd] R on Solaris 10 x64
Greg Nakhimovsky