search for: guestfs_internal_exit

...to use this option, you'll know that it didn't > work well. It broke random things (probably RHBZ#1020216, definitely > RHBZ#1023630), and caused random failures generally, while often not > actually failing when valgrind itself found problems. > > This does not remove the guestfs_internal_exit API. That will > instead be modified in a future commit. > --- I understand you don't like how it is currently done (and I might agree); OTOH, some of the stuff here could still be used when trying to valgrind the daemon within the appliance. Can you please leave this commit aside for n...

If you've ever tried to use this option, you'll know that it didn't work well. It broke random things (probably RHBZ#1020216, definitely RHBZ#1023630), and caused random failures generally, while often not actually failing when valgrind itself found problems. This does not remove the guestfs_internal_exit API. That will instead be modified in a future commit. --- appliance/Makefile.am | 7 +------ appliance/guestfsd.suppressions | 27 --------------------------- appliance/init | 20 +------------------- appliance/packagelist.in | 2 -- configure.ac...

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Previously posted here: https://www.redhat.com/archives/libguestfs/2015-June/msg00266.html Rich.

In v2: - Kernel command line parsing now moved to the appliance. - In the captive daemon test, the daemon cleanly shuts down on exit. - Add another btrfs test. Rich.

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to