On Tue, Dec 04, 2007 at 04:46:36PM -0800, John Reiser wrote:
> and enough changes
> to valgrind to tolerate more forms of clone()
I was going to ask whether you were treating the clone that creates
the userspace process differently from other clones, but I guess the
bit below answers that question:
> **24577** new_thread_handler fn=0x807FD8C arg=0x822AF48
> [snip: panic due to SIGSEGV seen from wait_stub_done()]
And I guess it's not treated differently and valgrind continues
grinding the child, and it craps out when it unmaps everything in the
child address space except the stubs.
Whether you want the userspace process to escape valgrind or not
depends on whether you want full-system analysis (which some people
do, and cachegrind in particular would be very interesting on a full
system) or whether you want to smoke out kernel bugs (which is my main
interest here).
It'll be easier to let the userspace child escape - invent an
annotation for "don't follow this clone".
Longer-term, following this clone and allowing full-system analysis
would require some thought. The first problem, of course, is that
about the first the stub does in the new process is unmap everything
but itself, including valgrind.
Jeff
--
Work email - jdike at linux dot intel dot com
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
