On 05/23/2014 12:49 PM, Jakub Hrozek wrote:
On Fri, May 23, 2014 at 12:39:55PM +0300, Nikolai Kondrashov wrote:
> On 05/21/2014 01:20 PM, Nikolai Kondrashov wrote:
>> On 05/19/2014 08:34 PM, Nikolai Kondrashov wrote:
>>> Yes, I managed not to notice this before, behind other errors, but I get
these
>>> too. It seems it is reall a Valgrind issue. I.e. it doesn't seem to make
sense
>>> to apply "--error-exitcode" to child processes.
>>>
>>> However, it seems that the exit status of the process in question is
hardcoded
>>> to zero. So, can we perhaps work this around for now by changing the
assertion
>>> to the following?
>>>
>>> verify_eq (WIFSIGNALED(child_status), 0);
>>>
>>> If yes, I'll submit a patch.
>>
>> Scratch that. The "--error-exitcode" option is useless with child
tracking,
>> anyway. Any errors in children will not affect exit code of the parent
>> Valgrind. I guess I'll have to do XML Valgrind output and analyze that.
>> Sigh...
>
> Nope. Valgrind's XML output is useless for forked programs. XML gets all
> jumbled up. Valgrind outputs to separate files only for children which exec'd.
>
> This leaves me with parsing plain text output, which is even worse.
> Besides, Valgrind seems to lose count of errors which happened after forking,
> but before exec'ing. Still, there doesn't seem to be a better way.
Why is there forking involved even with CK_FORK=no?
The test_dbus_setup_mock forks the sbus server.
Nick