Re: signal mask bug?

[Danek Duvall <duvall@xxxxxxxxxxxxxx>]

On Thu, Feb 16, 2017 at 09:48:36AM +0000, Peter Stephenson wrote:

> On Wed, 15 Feb 2017 20:10:44 -0800
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > But then when we reach prinjob() from the "jobs" command, pn->status of
> > that job has changed from -1 to 65535.
> > 
> > This happens at signals.c:525 in wait_for_processes(), when the status
> > returned from wait3(&status) [line 457] is assigned to it.
> 
> Or somewhere or other it's going through a cast to unsigned short, but
> that doesn't seem all that likely in the signal code, particularly POSIX
> style on a 32- or 64-bit architecture.
> 
> If it's Solaris *and* Linux it seems unlikely the status itself is
> doing anything funny, though, and that's passed back as int *...

So my colleague did some digging and found that the process is marked with
WCONTFLG, and that once that happens, you have to check WIFCONTINUED()
before anything else, because WCONTFLG overwrites all the bits.  He found
that the following patch worked for him:

    --- a/Src/signals.c   2015-09-04 13:38:13.000000000 -0700
    +++ b/Src/signals.c   2017-02-16 11:37:26.714503575 -0800
    @@ -510,6 +510,11 @@
                    struct timezone dummy_tz;
                    gettimeofday(&pn->endtime, &dummy_tz);
                    pn->status = status;
    +#ifdef WIFCONTINUED
    +               if (WIFCONTINUED(status))
    +                       pn->status = SP_RUNNING;
    +#endif
    +
                    pn->ti = ru;
     #else
                    update_process(pn, status);

though it occurred to me that it might be better placed in the loop in
printjob(), which already has an override for pn->status.

Thanks,
Danek