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

> 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
(dbx)

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++) {
             curr_len=len[curr_seq];
              memcpy ( ( char * ) ( tgath_buf ) , ( const char * 
) ( buf + off [curr_seq ] ) , curr_len );
             tgath_buf+=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.

Thanks.

-Greg



[Rd] R on Solaris 10 x64
Greg Nakhimovsky