[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMAKE 3.81 vs GMAKE 4.2
From: |
nikhil jain |
Subject: |
Re: GMAKE 3.81 vs GMAKE 4.2 |
Date: |
Thu, 23 Jan 2020 07:12:32 +0530 |
Ok thanks for the explanation.
The issue here is the child has been reaped but when i print the Live child
in job.c -
DB (DB_JOBS, (_("Live child 0x%08lx (%s) PID %ld %s\n"),
(unsigned long int) c, c->file->name,
(long) c->pid, c->remote ? _(" (remote)") : ""));
it shows me the PID which is already reaped just before this call to reap
children but looks like it is not freed up from running/live child list.
Because of this make goes into infinite loop on wait() call to reap a PID
which is already reaped.
Please help if you know about this problem
Thanks
Nikhil
On Wed, Jan 15, 2020 at 7:34 PM Paul Smith <address@hidden> wrote:
> On Tue, 2020-01-14 at 15:25 +0530, nikhil jain wrote:
> > Hi Paul,
> >
> > I am coming across a strange issue in gmake.
> > in Job.c there is a condition -
> >
> > /* Now try a blocking wait for a remote child. */
> > pid = remote_status (&exit_code, &exit_sig, &coredump, 1);
> >
> > this pid is coming as -1 and errorno set to 10 means no child.
>
> remote_status() tells you the result of waiting for *REMOTE* children.
> That is, children that are running on another host not the local host.
>
> The standard build of GNU make does not support any remote operations and
> it links in the remote-stub.c file which provides do-nothing versions of
> all the remote functions.
>
> In this case, the fact that remote_status() returns -1 means that there
> were no *remote* children running, it doesn't mean that there were no
> children at all running. When this status is returned make will continue
> processing local children.
>
>
>