Message ID | 20181121183936.8176-3-mathieu.desnoyers@efficios.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 114711 invoked by alias); 21 Nov 2018 18:39:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 114686 invoked by uid 89); 21 Nov 2018 18:39:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail.efficios.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com BFD50133E91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1542825588; bh=ngl4wbrkB57rB1enVPhbdC1GajG13YiJUmvhkmrNMtM=; h=From:To:Date:Message-Id; b=GXW583HgFM5tJKSxJNTsMO+SZR/pN8yAk7JmZiQln1Fx4H2b4q8AWHSx7NnF+yFNl cX0mMPHqjko4sdzCf40Hwko1TeHX/ExqZh5fAZeFcP0c6pOhgHbyybehu9AYAJHgyg 2RLHuV3BGANWq7idJ+pDpnE6Lsm3PgjHZDV/6Y45AhWWNBF3Rnhe3Jsyw/Gflfx3XG 0vCt7e9i/EPMgTycBa0SG3O69w39wgU5scrUlH7NQytXEXq9lDxBmnpzEfZTNkznSk ltGSvVXZo63e7Vb1XrqSOiIDj4ojrCWjUql97F4l+HYTnWiMHqZggL/s8UgZnXOHJo v59DTtHbxRy0w== From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Carlos O'Donell <carlos@redhat.com> Cc: Florian Weimer <fweimer@redhat.com>, Joseph Myers <joseph@codesourcery.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha@sourceware.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Subject: [RFC PATCH v4 3/5] support record failure: flush stdout, use _exit () Date: Wed, 21 Nov 2018 13:39:34 -0500 Message-Id: <20181121183936.8176-3-mathieu.desnoyers@efficios.com> In-Reply-To: <20181121183936.8176-1-mathieu.desnoyers@efficios.com> References: <20181121183936.8176-1-mathieu.desnoyers@efficios.com> |
Commit Message
Mathieu Desnoyers
Nov. 21, 2018, 6:39 p.m. UTC
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(-)
Comments
* 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
diff --git a/support/check.c b/support/check.c index 78f2b3cde1..bed1d20457 100644 --- a/support/check.c +++ b/support/check.c @@ -22,6 +22,7 @@ #include <stdarg.h> #include <stdio.h> #include <stdlib.h> +#include <unistd.h> #include <support/test-driver.h> static void @@ -56,5 +57,6 @@ support_exit_failure_impl (int status, const char *file, int line, va_start (ap, format); print_failure (file, line, format, ap); va_end (ap); - exit (status); + fflush (stdout); + _exit (status); }