Any idea Paul and Team ?
On Thu, Jan 23, 2020 at 7:12 AM nikhil jain <jainnikhi...@gmail.com> wrote:
> 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 <psm...@gnu.org> 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.
>>
>>
>>
