Bug 98444

Summary: valgrind fails to run against user-mode-linux (UML) process - clone
Product: [Developer tools] valgrind Reporter: das deniz <das_deniz>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED INTENTIONAL    
Severity: crash CC: njn, user-mode-linux-devel, vandebo-valgrind
Priority: NOR    
Version First Reported In: 2.3 CVS   
Target Milestone: ---   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: complete valgrind log of crash

Description das deniz 2005-02-02 22:02:05 UTC 
picking up this thread again:  

  http://marc.theaimsgroup.com/?l=user-mode-linux-devel&m=109152647819605&w=2

in valgrind 2.2.0 we had at best -- "clone(): not supported by Valgrind." and it
never went any further despite talk of old patches that would allow the clone
out from under valgrind to get to the next stopper.

but now in CVS HEAD, we no longer get this message, but instead we see:

SYSCALL[27839,1](120) special:sys_clone ( 11, 0x1BB4AFEC, 0x1BA40DA0, 0x8113360,
0x52BFE4F4 )==27839== Syscall param clone(parent_tidptr) contains uninitialised
byte(s)
==27839==    at 0x1B9EE4C9: clone (in /lib/libc-2.3.2.so)
==27839==    by 0x80BEBC8: can_do_skas (process.c:243)
==27839==    by 0x80C2DB3: linux_main (um_arch.c:332)
==27839==    by 0x80512BF: main (main.c:148)
==27839== 
==27839== Syscall param clone(tlsinfo) contains uninitialised byte(s)
==27839==    at 0x1B9EE4C9: clone (in /lib/libc-2.3.2.so)
==27839==    by 0x80BEBC8: can_do_skas (process.c:243)
==27839==    by 0x80C2DB3: linux_main (um_arch.c:332)
==27839==    by 0x80512BF: main (main.c:148)
==27839== 
==27839== Syscall param clone(child_tidptr) contains uninitialised byte(s)
==27839==    at 0x1B9EE4C9: clone (in /lib/libc-2.3.2.so)
==27839==    by 0x80BEBC8: can_do_skas (process.c:243)
==27839==    by 0x80C2DB3: linux_main (um_arch.c:332)
==27839==    by 0x80512BF: main (main.c:148)
   clone(fork): process 27839 created child 27840
 --> 0 (0x0)
==27840== 
==27840== Jump to the invalid address stated on the next line
==27840==    at 0x7: ???
==27840==  Address 0x7 is not stack'd, malloc'd or (recently) free'd
==27840== 
==27840== Process terminating with default action of signal 11 (SIGSEGV)
==27840==  Access not within mapped region at address 0x7
==27840==    at 0x7: ???
Comment 1 das deniz 2005-02-02 22:11:24 UTC 
Created attachment 9396 [details]
complete valgrind log of crash
Comment 2 Jeremy Fitzhardinge 2005-02-03 02:17:01 UTC 
Hm, nothing obvious sticks out.  That clone() is basically just a fork() with no special options, which Valgrind has supported for a long time, so I'm not sure what's going on there.  The warnings about tlsinfo and *_tidptr are spurious.

It seems the child process just jumps to 0x7 as soon as it starts running...

Is there any difference with --tool=none?

BTW, you're still going to get bitten by stack switching with memcheck and addrcheck.
Comment 3 Steve VanDeBogart 2008-08-28 02:18:56 UTC 
There is now a wiki page that describes how to get valgrind to work with User Mode Linux here: http://uml.jfdi.org/uml/Wiki.jsp?page=ValgrindingUML
Comment 4 Nicholas Nethercote 2009-07-02 06:11:20 UTC 
I'm closing crashing and similar bugs that are more than two years old.  If
you still see this problem with Valgrind 3.4.1 please reopen the bug report.
Thanks.