[RFC,v4,3/5] support record failure: flush stdout, use _exit ()

  Using "exit ()" from pthread_atfork handlers hangs the process. It is
therefore not a good way to exit when reporting a testing error.

Use _exit () instead, which directly exits the process. However,
considering that the buffered stdout is used to output test failure
messages, we first need to flush stdout before exiting.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Carlos O'Donell <carlos@redhat.com>
CC: Florian Weimer <fweimer@redhat.com>
CC: Joseph Myers <joseph@codesourcery.com>
CC: Szabolcs Nagy <szabolcs.nagy@arm.com>
CC: libc-alpha@sourceware.org
---
 support/check.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
  

* Mathieu Desnoyers:

> Using "exit ()" from pthread_atfork handlers hangs the process. It is
> therefore not a good way to exit when reporting a testing error.
>
> Use _exit () instead, which directly exits the process. However,
> considering that the buffered stdout is used to output test failure
> messages, we first need to flush stdout before exiting.

This is not correct; we need the atexit handlers for cleaning up
temporary files.

It should be possible to call support_record_failure and rely on the
shared memory segment to register the test failure, so that it is
eventually reflected in the exit state (even if the failure happens in
the subprocess).

Thanks,
Florian
  

----- On Nov 21, 2018, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:

> * Mathieu Desnoyers:
> 
>> Using "exit ()" from pthread_atfork handlers hangs the process. It is
>> therefore not a good way to exit when reporting a testing error.
>>
>> Use _exit () instead, which directly exits the process. However,
>> considering that the buffered stdout is used to output test failure
>> messages, we first need to flush stdout before exiting.
> 
> This is not correct; we need the atexit handlers for cleaning up
> temporary files.
> 
> It should be possible to call support_record_failure and rely on the
> shared memory segment to register the test failure, so that it is
> eventually reflected in the exit state (even if the failure happens in
> the subprocess).

Calling exit() from a pthread_atfork handler unfortunately seems to hang
the process :-/

What would you recommend to deal with that situation ?

Thanks,

Mathieu

> 
> Thanks,
> Florian
  

----- On Nov 21, 2018, at 1:52 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

> ----- On Nov 21, 2018, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:
> 
>> * Mathieu Desnoyers:
>> 
>>> Using "exit ()" from pthread_atfork handlers hangs the process. It is
>>> therefore not a good way to exit when reporting a testing error.
>>>
>>> Use _exit () instead, which directly exits the process. However,
>>> considering that the buffered stdout is used to output test failure
>>> messages, we first need to flush stdout before exiting.
>> 
>> This is not correct; we need the atexit handlers for cleaning up
>> temporary files.
>> 
>> It should be possible to call support_record_failure and rely on the
>> shared memory segment to register the test failure, so that it is
>> eventually reflected in the exit state (even if the failure happens in
>> the subprocess).
> 
> Calling exit() from a pthread_atfork handler unfortunately seems to hang
> the process :-/
> 
> What would you recommend to deal with that situation ?

Or do you mean _not_ exiting from the pthread_atfork handlers, but just
record the error there, and continue normally, then catch the error in
the parent ?

Thanks,

Mathieu

> 
> Thanks,
> 
> Mathieu
> 
>> 
>> Thanks,
>> Florian
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
  

* Mathieu Desnoyers:

> ----- On Nov 21, 2018, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>> 
>>> Using "exit ()" from pthread_atfork handlers hangs the process. It is
>>> therefore not a good way to exit when reporting a testing error.
>>>
>>> Use _exit () instead, which directly exits the process. However,
>>> considering that the buffered stdout is used to output test failure
>>> messages, we first need to flush stdout before exiting.
>> 
>> This is not correct; we need the atexit handlers for cleaning up
>> temporary files.
>> 
>> It should be possible to call support_record_failure and rely on the
>> shared memory segment to register the test failure, so that it is
>> eventually reflected in the exit state (even if the failure happens in
>> the subprocess).
>
> Calling exit() from a pthread_atfork handler unfortunately seems to hang
> the process :-/
>
> What would you recommend to deal with that situation ?

Why do you want to terminate the process there?  Is this part of the
test?

Thanks,
Florian
  

* Mathieu Desnoyers:

> ----- On Nov 21, 2018, at 1:52 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
>
>> ----- On Nov 21, 2018, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:
>> 
>>> * Mathieu Desnoyers:
>>> 
>>>> Using "exit ()" from pthread_atfork handlers hangs the process. It is
>>>> therefore not a good way to exit when reporting a testing error.
>>>>
>>>> Use _exit () instead, which directly exits the process. However,
>>>> considering that the buffered stdout is used to output test failure
>>>> messages, we first need to flush stdout before exiting.
>>> 
>>> This is not correct; we need the atexit handlers for cleaning up
>>> temporary files.
>>> 
>>> It should be possible to call support_record_failure and rely on the
>>> shared memory segment to register the test failure, so that it is
>>> eventually reflected in the exit state (even if the failure happens in
>>> the subprocess).
>> 
>> Calling exit() from a pthread_atfork handler unfortunately seems to hang
>> the process :-/
>> 
>> What would you recommend to deal with that situation ?
>
> Or do you mean _not_ exiting from the pthread_atfork handlers, but just
> record the error there, and continue normally, then catch the error in
> the parent ?

Yes, support_record_failure is for delayed failure reporting.

Thanks,
Florian
  

----- On Nov 21, 2018, at 1:56 PM, Florian Weimer fweimer@redhat.com wrote:

> * Mathieu Desnoyers:
> 
>> ----- On Nov 21, 2018, at 1:52 PM, Mathieu Desnoyers
>> mathieu.desnoyers@efficios.com wrote:
>>
>>> ----- On Nov 21, 2018, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:
>>> 
>>>> * Mathieu Desnoyers:
>>>> 
>>>>> Using "exit ()" from pthread_atfork handlers hangs the process. It is
>>>>> therefore not a good way to exit when reporting a testing error.
>>>>>
>>>>> Use _exit () instead, which directly exits the process. However,
>>>>> considering that the buffered stdout is used to output test failure
>>>>> messages, we first need to flush stdout before exiting.
>>>> 
>>>> This is not correct; we need the atexit handlers for cleaning up
>>>> temporary files.
>>>> 
>>>> It should be possible to call support_record_failure and rely on the
>>>> shared memory segment to register the test failure, so that it is
>>>> eventually reflected in the exit state (even if the failure happens in
>>>> the subprocess).
>>> 
>>> Calling exit() from a pthread_atfork handler unfortunately seems to hang
>>> the process :-/
>>> 
>>> What would you recommend to deal with that situation ?
>>
>> Or do you mean _not_ exiting from the pthread_atfork handlers, but just
>> record the error there, and continue normally, then catch the error in
>> the parent ?
> 
> Yes, support_record_failure is for delayed failure reporting.

Good. I'll favor returning errors back to do_test () whenever possible.

When it's not, I'll use delayed failure reporting rather that FAIL_EXIT1 ()
when the test needs to report an error and has not way to return it to
do_test ().

I'll keep FAIL_EXIT1 for "setup" errors that are outside of the scope of
what the test is actually testing, and also for execution contexts running
after main exits (atexit handler, destructors, pthread key destroy,
__call_tls_dtors.

Thanks,

Mathieu