* [Bug driver/112836] gcc fails when job control is used
2023-12-03 19:14 [Bug driver/112836] New: gcc fails when job control is used bruno at clisp dot org
@ 2023-12-03 19:17 ` bruno at clisp dot org
2023-12-04 6:52 ` [Bug other/112836] " sjames at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: bruno at clisp dot org @ 2023-12-03 19:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 56779
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56779&action=edit
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/112836] gcc fails when job control is used
2023-12-03 19:14 [Bug driver/112836] New: gcc fails when job control is used bruno at clisp dot org
2023-12-03 19:17 ` [Bug driver/112836] " bruno at clisp dot org
@ 2023-12-04 6:52 ` sjames at gcc dot gnu.org
2023-12-04 8:43 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: sjames at gcc dot gnu.org @ 2023-12-04 6:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
Thanks for chasing this down. This has been driving me nuts for a while but I
hadn't dug into it yet.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/112836] gcc fails when job control is used
2023-12-03 19:14 [Bug driver/112836] New: gcc fails when job control is used bruno at clisp dot org
2023-12-03 19:17 ` [Bug driver/112836] " bruno at clisp dot org
2023-12-04 6:52 ` [Bug other/112836] " sjames at gcc dot gnu.org
@ 2023-12-04 8:43 ` rguenth at gcc dot gnu.org
2024-02-01 18:21 ` glaubitz at physik dot fu-berlin.de
2024-02-01 21:42 ` bruno at clisp dot org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-04 8:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-12-04
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you post it to gcc-patches@gcc.gnu.org please?
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/112836] gcc fails when job control is used
2023-12-03 19:14 [Bug driver/112836] New: gcc fails when job control is used bruno at clisp dot org
` (2 preceding siblings ...)
2023-12-04 8:43 ` rguenth at gcc dot gnu.org
@ 2024-02-01 18:21 ` glaubitz at physik dot fu-berlin.de
2024-02-01 21:42 ` bruno at clisp dot org
4 siblings, 0 replies; 6+ messages in thread
From: glaubitz at physik dot fu-berlin.de @ 2024-02-01 18:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #4 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I tried this patch but it does not address the issue with posix_spawn that I am
seeing.
Trying to build gcc from git on Linux sparc64 with glibc 2.37 with the
following configuration:
./configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
--disable-nls --host=sparc64-unknown-linux-gnu
fails with:
xgcc: fatal error: cannot execute '/home/glaubitz/gcc/build/./gcc/cc1plus':
posix_spawn: Bad address
compilation terminated.
This can be worked around when building with one parallel job (make -j1).
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/112836] gcc fails when job control is used
2023-12-03 19:14 [Bug driver/112836] New: gcc fails when job control is used bruno at clisp dot org
` (3 preceding siblings ...)
2024-02-01 18:21 ` glaubitz at physik dot fu-berlin.de
@ 2024-02-01 21:42 ` bruno at clisp dot org
4 siblings, 0 replies; 6+ messages in thread
From: bruno at clisp dot org @ 2024-02-01 21:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #5 from Bruno Haible <bruno at clisp dot org> ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> I tried this patch but it does not address the issue with posix_spawn that I
> am seeing.
>
> Trying to build gcc from git on Linux sparc64 with glibc 2.37 with the
> following configuration:
>
> ./configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
> --disable-nls --host=sparc64-unknown-linux-gnu
>
> fails with:
>
> xgcc: fatal error: cannot execute '/home/glaubitz/gcc/build/./gcc/cc1plus':
> posix_spawn: Bad address
> compilation terminated.
>
> This can be worked around when building with one parallel job (make -j1).
This appears to be a different bug, because
- it appears under different conditions (parallel make, not Ctrl-Z / 'fg'),
- the message is different ("posix_spawn: Bad address", not "failed to get
exit status: Interrupted system call").
Could you please register it as a separate bug under
https://gcc.gnu.org/bugzilla/ ?
^ permalink raw reply [flat|nested] 6+ messages in thread