On 2021-08-02 03:52:27 +0200, Vincent Lefevre wrote:
> On 2021-08-02 02:45:58 +0200, Axel Beckert wrote:
> > So I will start experimenting with the patches suggested by upstream
> > in the upstream bug report again.
>
> Also try the volatile as I suggested (and see if this leads to a
> change of the generated code). Otherwise, the code seems correct;
> well, unless I've missed something, at least it shouldn't leave
> zombies (except if wait4 fails, but I wonder how this could occur).
FYI, I've tested with volatile, but this doesn't solve the problem.
I've also looked at the generated code, and a read of GotSigChld
has been added, but one that isn't actually necessary with the
current code. The loop was already present, but only because the
compiler wasn't smart enough; with more advanced optimizations
(possibly with -O3 instead of -O2, or with future versions of GCC,
or with a simplification of the DoWait code), the loop could be
transformed into incorrect code.
In details, one has:
static void serv_select_fn(struct event *ev, char *data)
{
struct win *p;
debug("serv_select_fn called\n");
/* XXX: messages?? */
if (GotSigChld)
SigChldHandler();
[...]
where SigChldHandler is:
static void SigChldHandler()
{
struct stat st;
#ifdef DEBUG
fds();
#endif
while (GotSigChld) {
GotSigChld = 0;
DoWait();
#ifdef SYSVSIGS
signal(SIGCHLD, SigChld);
#endif
}
[...]
The compiler detects the two consecutive tests of GotSigChld
(the first one in "if", the second one in "while"), and it just
does one test. With volatile, this optimization is forbidden.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
