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: ???
Created attachment 9396 [details] complete valgrind log of crash
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.
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
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.