From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 8C66C3858C35; Sun,  3 Dec 2023 19:17:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C66C3858C35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1701631021;
	bh=HkzYDBNH375whmeki4rBxdPMpVLuBKfDdNrxWlQMZpc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=bNOcjXTSVRl0pimItppfgiSnLMigClKYSW0QAdIB4M+CxBQ4GkN1AuOgMfzDC4gmw
	 rKOsIJB2ccYEOi4ZUVyDbiPz/X7aD9g2oJ5uAQuK4nERxrxnHDNr68UPS96fWkl85/
	 AUbwMuVg01qg+5RFZTDdH/B8MTEO7Kh1GUoDgbTw=
From: "bruno at clisp dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/112836] gcc fails when job control is used
Date: Sun, 03 Dec 2023 19:17:01 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: 13.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bruno at clisp dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-112836-4-HW1YMQ4bvj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112836-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112836-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112836

--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 56779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D56779&action=3Dedit
proposed fix

Although the error is not easily reproducible, it is easy to analyze
and fix:

The piece of error message string "failed to get exit status" occurs
only in one place: in gcc/gcc.cc line 3462.

The only possible cause for the error message
"failed to get exit status: Interrupted system call" is therefore
that pex_get_status returned 0, with error code EINTR.

pex_get_status is defined in libiberty/pex-common.c, line 547.
It returns 0 only in line 555. We can infer that the function
pex_get_status_and_time had returned 0, with error code EINTR.

pex_get_status_and_time is defined in libiberty/pex-common.c, line 518.
It returns 0 only when ret gets to 0 in line 537. We can infer
that the obj->funcs->wait function must have returned non-zero,
with error code EINTR.

obj->funcs->wait is the method declared in libiberty/pex-common.h
line 128. On this platform, the relevant implementation is in
libiberty/pex-unix.c. The initialization happens in
libiberty/pex-unix.c line 338:
  return pex_init_common (flags, pname, tempbase, &funcs);
The obj->funcs->wait function function is thus pex_unix_wait.
It must have returned non-zero, with error code EINTR.

pex_unix_wait is defined in libiberty/pex-unix.c line 938.
Looking at its code, the function pex_wait must have returned a
negative value, with errno being set to EINTR.

pex_wait has 4 possible implementations, in
  libiberty/pex-unix.c line 128
  libiberty/pex-unix.c line 159
  libiberty/pex-unix.c line 170
  libiberty/pex-unix.c line 219
Since glibc has the 'wait4' function, the implementation that
matters is the one from libiberty/pex-unix.c line 128. But the
other implementations have the same problem: they don't handle
EINTR so far.

Find attached a proposed patch.=