Re: [Valgrind-developers] 64k pages on PPC

[Nicholas N. <nj...@cs...>]

On Wed, 18 Oct 2006, Dave Nomura wrote:

> I found some more places that uses VKI_PAGE_SIZE in m_ume.c.  The two 
> references in mapelf() and load_ELF() look like they are using VKI_PAGE_SIZE 
> as "the pagesize", but the two references in load_script() and 
> VG_(pre_exec_check) are, I believe, using VKI_PAGE_SIZE is just a 
> sufficiently large chunk of buffer size to read in enough of the script, or 
> elf executable file to file to be able to call match_ELF(), match_script() or 
> to parse some of the stuff in the interpreter script.  Since my change makes 
> VKI_PAGE_SIZE a variable, I replaced these two references in load_script() 
> and VG_(pre_exec_check) by VKI_STATIC_PAGE_SIZE which was the larger of the 
> two possible choices.  This caused problems because it was pushing onto the 
> stack an array of 64K bytes and was overflowing the stack.  In 
> VG_(pre_exec_check) the call to VG_(pread) was writing onto some of my global 
> variables and the program crashed.
>
> The change I am proposing is to replace these two references to VKI_PAGE_SIZE 
> in load_script() and VG_(pre_exec_check) by INITIAL_CHUNK_SIZE which I've 
> defined locally as 4K.

Nice detective work!  INITIAL_CHUNK_SIZE == 4k sounds reasonable to me.

> How does this sound to you?  I can now run the regression test suite although 
> I get a lot of diffs like:
> exitprog.stderr.diff
> + WARNING: Thread 1 is within 50576 bytes of running out of stack!
> Can you think of a reason why the stack usage would be different on a machine 
> with a different pagesize? Are there some pagesize chunks of memory allocated 
> that would reduce the amount of space available for the stack?
> Maybe there is some other area that requires some pagesize dependent changes?

I don't know about that.  Maybe that check detects if you are within 
VKI_PAGE_SIZE of running out of stack?  Which with 64KB pages isn't a big 
deal, but with 4KB pages it's more dangerous.  If so, changing the constant 
again to 4KB (with a different name) seems reasonable.

> pointer-trace.stderr.diff
> *** 20 ****
> ! 1,048,576 bytes in 1 blocks are definitely lost in loss record 1 of 1
> --- 20 ----
> ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1
> No idea what might cause this difference.

I'm pretty sure that's harmless, just random noise.

> pointer-trace.stderr.diff64
> *** 20 ****
> ! 2,097,152 bytes in 1 blocks are definitely lost in loss record 1 of 1
> --- 20 ----
> ! 1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1
> Does this look at all familiar?  Any guesses why twice as many blocks would 
> be lost?  definittely vs. possibly?

I don't know about that one, but pointer-trace fails all the time in the 
nightly regression tests.  The .exp64 output might just be wrong?

Nick