On 05/23/2014 01:00 PM, Nikolai Kondrashov wrote:
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.
Anyway, we shouldn't rule out the need to fork in tests.
Nick