search for: 1023630

In data giovedì 25 giugno 2015 15:56:53, Richard W.M. Jones ha scritto: > 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. > --- I understand you don't like how it is currently don...

In data giovedì 25 giugno 2015 14:50:03, Richard W.M. Jones ha scritto: > We had a chat about this on IRC, and I'm not very happy about any > patch that requires a special ./configure flag. I'm not sure where you see any special ./configure flag, other than what is already there (and not used much because makes things cumbersome). > We should find a way > to enable this

...aster/src/handle.c#L429-L443 https://github.com/libguestfs/libguestfs/blob/master/src/conn-socket.c#L346-L364 We shouldn't have two different paths that developers and non- developers use. (2) This actually causes bugs. The second one is the race. https://bugzilla.redhat.com/show_bug.cgi?id=1023630 https://bugzilla.redhat.com/show_bug.cgi?id=1020216 There's also another race which I don't think we have a bug about where the output from valgrind is truncated (because valgrind is quite slow at shutdown) so that you don't see valgrind errors reliably. Attempting (not always successf...

Hi John, Welcome, and this is a frequent newbie question: in LLVM names are more for human readability of the code, they are not really used as references internally. Instead engine operates instructions, which could be "used by" or "user of" other instructions (see use_iterator of Value.h). Also the Function class has an iterator of BasicBlocks, and each BasicBlock has an

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 |...

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