On Wed, Jun 8, 2011 at 9:39 PM, Scott James Remnant <[email protected]> wrote: > The problem with valgrind is the same as the general problem with gdb; init > needs to be pid 1, and these processes then can't trace it/emulate it. > Scott
Hi, This all seems quite familiar. I know initng used to have a kernel patch you could apply to work around this issue, though that's long since out of date. Not sure if I ever ran valgrind on pid 1 though. In fact, I think the big problem was that if it detected a serious enough memory access violation, valgrind forcibly terminated init, bypassing any SIGSEGV handler and causing a kernel panic due to pid 1 exiting. Basically: you don't want to do that. If you need to do so, I suggest using a VM with the console attached to somewhere that the messages will survive a kernel panic within the VM. If you can somehow manage to test whatever it is you need without running upstart as pid 1 that will make your life a lot easier. Hope that helps, Aidan (Apologies for any duplicates, I sent this from the wrong address.) -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
