From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 00DE1395BC09 for ; Wed, 27 May 2020 15:21:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 00DE1395BC09 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-377-f-MyIpogOdWM9ck0GsVYZA-1; Wed, 27 May 2020 11:21:05 -0400 X-MC-Unique: f-MyIpogOdWM9ck0GsVYZA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8CC8580183C; Wed, 27 May 2020 15:21:04 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-106.ams2.redhat.com [10.36.113.106]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B24155D9E5; Wed, 27 May 2020 15:21:03 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: libc-alpha , Joseph Myers Subject: Re: [PATCH glibc 3/3] rseq registration tests (v10) References: <20200501021439.2456-1-mathieu.desnoyers@efficios.com> <20200501021439.2456-4-mathieu.desnoyers@efficios.com> <871rnedgjg.fsf@oldenburg2.str.redhat.com> <1384708804.33510.1590426460701.JavaMail.zimbra@efficios.com> <87h7w2rhg2.fsf@oldenburg2.str.redhat.com> <1647263261.34186.1590504195448.JavaMail.zimbra@efficios.com> <87blm9h0o1.fsf@oldenburg2.str.redhat.com> <1218946966.36797.1590592662832.JavaMail.zimbra@efficios.com> Date: Wed, 27 May 2020 17:21:02 +0200 In-Reply-To: <1218946966.36797.1590592662832.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Wed, 27 May 2020 11:17:42 -0400 (EDT)") Message-ID: <87367lh09t.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 15:21:40 -0000 * Mathieu Desnoyers: > ----- On May 27, 2020, at 11:12 AM, Florian Weimer fweimer@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>>>>>> + retpid = TEMP_FAILURE_RETRY (waitpid (pid, &status, 0)); >>>>>>> + if (retpid != pid) >>>>>>> + { >>>>>>> + FAIL_EXIT1 ("waitpid returned %ld, expected %ld", >>>>>>> + (long int) retpid, (long int) pid); >>>>>>> + } >>>>>> >>>>>> Hmm. Is the TEMP_FAILURE_RETRY really needed? Our xwaitpid does not >>>>>> have this. >>>>> >>>>> Then how does it deal with a signal interrupting the system call performing >>>>> the waitpid (EINTR) ? I do not see WNOHANG being used. >>>> >>>> It obscures spurious signals. In most test cases, if an unexpected >>>> signal is delivered, something is quite wrong indeed. This is why we >>>> don't generally hide EINTR errors. >>> >>> So it means you may have trouble using tools like strace and gdb on those >>> tests ? AFAIU those are heavy users of SIGSTOP and SIGCONT. Similarly for >>> profilers, those usually rely on a timer-driven signal. >> >> I have never seen any problems with strace due to this. ptrace has >> become a bit more transparent to the tracee since the early days, I >> think. >> >> I haven't seen problems under GDB, either, but then tests that fork can >> be rather annoying to debug anyway. > > OK so I'll use the xwaitpid wrapper and let this be someone else's problem. Yes please. Or support_isolate_in_subprocess. Thanks, Florian