From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id C21B93851C12 for ; Wed, 27 May 2020 15:12:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C21B93851C12 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-7-unx4FivSMYu7ZtNcGZleFw-1; Wed, 27 May 2020 11:12:34 -0400 X-MC-Unique: unx4FivSMYu7ZtNcGZleFw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 49DF3461; Wed, 27 May 2020 15:12:33 +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 6062126358; Wed, 27 May 2020 15:12:32 +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> Date: Wed, 27 May 2020 17:12:30 +0200 In-Reply-To: <1647263261.34186.1590504195448.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Tue, 26 May 2020 10:43:15 -0400 (EDT)") Message-ID: <87blm9h0o1.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.84 on 10.5.11.23 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_H4, 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:12:41 -0000 * 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. Thanks, Florian