«

My scipt is using fork so there are child processes. Sometimes my
script runs properly and output is correct. But sometime my script
gets stuck just after exiting child process. And this does happen
always.

I am not sure why is this happening. Any suggestion or how can I debug
my script.

Below is psudo code. (not sure if this helps, it is juist snap shot)



foreach my $w (keys %worklist) {
my $child;
unless ($child = fork()) {
die("connot for: $!") unless defined $child;

foreach my $file (@{$worklist{$w}}) {
#reading files processing of data and
creating hash tables.
}

#ouput files from hash tables. outfile files will be
for each child.

print "Worker $w exiting\n"; #child
exiting
(#it gets stuck after printing this statement)

exit;
}
push(@workers, $child); #array of child PID
}

#wating for each child to finish.
foreach my $pid (@workers) {
$s = waitpid($pid, 0);
print "$s finished\n";
}



Thanks.

On Aug 3, 7:37*am, "friend...@gmail.com" <hirenshah...@gmail.com>
wrote:
> My scipt is using fork so there are child processes. Sometimes my
> script runs properly and output is correct. But sometime my script
> gets stuck just after exiting child process. And this does happen
> always.
>
> I am not sure why is this happening. Any suggestion or how can I debug
> my script.
>
> Below is psudo code. (not sure if this helps, it is juist snap shot)
>
> foreach my $w (keys %worklist) {
> * * * * my $child;
> * * * * unless ($child = fork()) {
> * * * * die("connot for: $!") unless defined $child;
>
> * * * * * * * * foreach my $file (@{$worklist{$w}}) {
> * * * * * * * * * * * * * #reading files processing of data and
> creating hash tables.
> * * * * * * * * }
>
> * * * * * * * *#ouput files from hash tables. outfile files will be
> for each child.
>
> * * * * * * * * * * * * print "Worker $w exiting\n"; * * * * *#child
> exiting
> (#it gets stuck after printing this statement)
>
> * * * * * * * * * * * * exit;
> * * * * }
> * * * * * *push(@workers, $child); * * * * * * #array of child PID
>
> }
>
> #wating for each child to finish.
> foreach my $pid (@workers) {
> * * * * * * * * *$s = waitpid($pid, 0);
> * * * * print "$s finished\n";
>
> }
>

Are you sure the parent isn't stuck waiting for a
particular child to finish...? You could check the
timeline as they're reaped:


foreach my $pid (@workers) {
print scalar localtime time(),
" waiting on $pid\n";
my $reaped = waitpid($pid, 0);
print scalar localtime time(),
" reaped $reaped (status=$?)\n\n";
}
print "finished...\n";

If you control the code the child is running, you can
probably pinpoint where the hang happens. If that's not
possible or you just need to limit the parent's wait on
any particular child, see: perldoc -q "slow event"


--
Charles DeRykus

wrote:
> My scipt is using fork so there are child processes. Sometimes my
> script runs properly and output is correct. But sometime my script
> gets stuck just after exiting child process. And this does happen
> always.

I am confused. The freeze happens sometimes, or it happens always?

<I've applied some reformatting>

>
> foreach my $w (keys %worklist) {
> my $child;
> unless ($child = fork()) {
> die("connot for: $!") unless defined $child;
> foreach my $file (@{$worklist{$w}}) {
> #reading files processing of data and creating hash tables.
> }
> print "Worker $w exiting\n";

I'd print $$ here as well.

> #it gets stuck after printing this statement

How do you know? What are you expecting to see that you do not see?
What system monitoring tool do you use to know that it has not exited?

>
> exit;
> }
> push(@workers, $child); #array of child PID
> }
>
> #wating for each child to finish.
> foreach my $pid (@workers) {

print "About to wait for $pid\n";

> $s = waitpid($pid, 0);
> print "$s finished\n";
> }
>
>

Xho

On Aug 4, 12:25*am, Xho Jingleheimerschmidt <xhos...@gmail.com> wrote:
> friend...@gmail.com wrote:
> > My scipt is using fork so there are child processes. Sometimes my
> > script runs properly and output is correct. But sometime my script
> > gets stuck just after exiting child process. And this does happen
> > always.
>
> I am confused. *The freeze happens sometimes, or it happens always?
>
> <I've applied some reformatting>
>
>
>
> > foreach my $w (keys %worklist) {
> > * *my $child;
> > * *unless ($child = fork()) {
> > * * * * * * *die("connot for: $!") unless defined $child;
> > * * * * * * * * foreach my $file (@{$worklist{$w}}) {
> > * * * * * * * * * * * * * #reading files processing of data and creating hash tables.
> > * * * * * * * * }
> > * * * * * * * * print "Worker $w exiting\n";
>
> I'd print $$ here as well.
>
> > * * * * * * * * #it gets stuck after printing this statement
>
> How do you know? *What are you expecting to see that you do not see?
> What system monitoring tool do you use to know that it has not exited?
>
>
>
> > * * * * * * * * exit;
> > * *}
> > * * * * * *push(@workers, $child); * #array of child PID
> > }
>
> > #wating for each child to finish.
> > foreach my $pid (@workers) {
>
> * * * * *print "About to wait for $pid\n";
>
> > * * * $s = waitpid($pid, 0);
> > * *print "$s finished\n";
> > }
>
> Xho

The freeze happens sometimes.

And I check the trace(truss -p on sun). I found that sometimes one of
the child goes to sleeping and parent is still waiting for that child
exit status. But it never gets that bcoz child is sleeping.

And once this does happens only sometimes. Sometime everything works
fine.

And suggestion what can be problem or else how can I debug more.

Thanks

wrote:
>
> And I check the trace(truss -p on sun). I found that sometimes one of
> the child goes to sleeping and parent is still waiting for that child
> exit status. But it never gets that bcoz child is sleeping.

What system call does it use to put itself to sleep? You are quite sure
that it reaches the "exit" before going to sleep? If it prints its
exiting message immediately before the exit, what do you see in the
strace between the "write" (or whatever system call does the actual
printing) and the command that puts it to sleep?

Xho

On Aug 6, 9:47*pm, Xho Jingleheimerschmidt <xhos...@gmail.com> wrote:
> friend...@gmail.com wrote:
>
> > And I check the trace(truss -p on sun). I found that sometimes one of
> > the child goes to sleeping and parent is still waiting for that child
> > exit status. But it never gets that bcoz child is sleeping.
>
> What system call does it use to put itself to sleep? *You are quite sure
> that it reaches the "exit" before going to sleep? *If it prints its
> exiting message immediately before the exit, what do you see in the
> strace between the "write" (or whatever system call does the actual
> printing) and the command that puts it to sleep?
>
> Xho

before sleeping child was trying to read something.

any suggestion how can I debug exactly what child is trying to read.

In article
<29a9dc9e-add1-4369-9650->,
<""> wrote:

> On Aug 6, 9:47*pm, Xho Jingleheimerschmidt <xhos...@gmail.com> wrote:
> > friend...@gmail.com wrote:
> >
> > > And I check the trace(truss -p on sun). I found that sometimes one of
> > > the child goes to sleeping and parent is still waiting for that child
> > > exit status. But it never gets that bcoz child is sleeping.
> >
> > What system call does it use to put itself to sleep? *You are quite sure
> > that it reaches the "exit" before going to sleep? *If it prints its
> > exiting message immediately before the exit, what do you see in the
> > strace between the "write" (or whatever system call does the actual
> > printing) and the command that puts it to sleep?
> >
> > Xho
>
> before sleeping child was trying to read something.
>
> any suggestion how can I debug exactly what child is trying to read.

Print out what the child has read after the child has read it?

--
Jim Gibson

wrote:
> On Aug 6, 9:47 pm, Xho Jingleheimerschmidt <xhos...@gmail.com> wrote:
>> friend...@gmail.com wrote:
>>
>>> And I check the trace(truss -p on sun). I found that sometimes one of
>>> the child goes to sleeping and parent is still waiting for that child
>>> exit status. But it never gets that bcoz child is sleeping.
>> What system call does it use to put itself to sleep? You are quite sure
>> that it reaches the "exit" before going to sleep? If it prints its
>> exiting message immediately before the exit, what do you see in the
>> strace between the "write" (or whatever system call does the actual
>> printing) and the command that puts it to sleep?
>>
>> Xho
>
> before sleeping child was trying to read something.

It actually read something, and then put itself to sleep?
Or the read itself was the thing that it was blocking (i.e. sleeping) on?

> any suggestion how can I debug exactly what child is trying to read.

I'm more used to to strace than truss. But if you you have (from the
truss) the file handle it is trying to read from, you should be able to
go back through the truss output, assuming you saved enough of it, to
see what that file handle was opened to (presumably it will not be an
ordinary file, as those tend not to block, but rather some sort of pipe
or socket).

And if that doesn't work....Since you (presumably) wrote the child code,
and haven't shared it with us, we are in a poor place to guess about
what it could be trying to read, while you should be an excellent place
to guess on that.

Xho

On Aug 11, 10:06*pm, Xho Jingleheimerschmidt <xhos...@gmail.com>
wrote:
> friend...@gmail.com wrote:
> > On Aug 6, 9:47 pm, Xho Jingleheimerschmidt <xhos...@gmail.com> wrote:
> >> friend...@gmail.com wrote:
>
> >>> And I check the trace(truss -p on sun). I found that sometimes one of
> >>> the child goes to sleeping and parent is still waiting for that child
> >>> exit status. But it never gets that bcoz child is sleeping.
> >> What system call does it use to put itself to sleep? *You are quite sure
> >> that it reaches the "exit" before going to sleep? *If it prints its
> >> exiting message immediately before the exit, what do you see in the
> >> strace between the "write" (or whatever system call does the actual
> >> printing) and the command that puts it to sleep?
>
> >> Xho
>
> > before sleeping child was trying to read something.
>
> It actually read something, and then put itself to sleep?
> Or the read itself was the thing that it was blocking (i.e. sleeping) on?
>
> > any suggestion how can I debug exactly what child is trying to read.
>
> I'm more used to to strace than truss. *But if you you have (from the
> truss) the file handle it is trying to read from, you should be able to
> go back through the truss output, assuming you saved enough of it, to
> see what that file handle was opened to (presumably it will not be an
> ordinary file, as those tend not to block, but rather some sort of pipe
> or socket).
>
> And if that doesn't work....Since you (presumably) wrote the child code,
> and haven't shared it with us, we are in a poor place to guess about
> what it could be trying to read, while you should be an excellent place
> to guess on that.
>
> Xho- Hide quoted text -
>
> - Show quoted text -


Before forking I have following code of OPEN2.

open2(*README,*WRITEME,"......");

I am using README and WRITEME in my child processes.

So do I have to include OPEN2 statement in child process or not ???

Thanks for ur help