Alan Coopersmith wrote:
> Matt Keenan wrote:
>> Fix for bug : 6702990, bugzilla : 17876
>>
>> Couple of issues here :
>>
>> 1. rarian forks a process to run "manpath", this child was exiting using
>> exit(0)
>> call instead of _exit(0) call, resulting in some file descriptors
>> being left
>> open for the child. And later on these FD's were being constantly polled
>> which resulted in CPU usage going nuts. Solution is to simply call
>> _exit(0)
>> which closes the child env properly.
>
> execlp("manpath", "manpath", (char *) 0);
> - exit (0);
> + _exit (0);
In our case (solaris), execlp() will fail as "manpath", does not exist on
solaris it's a linux only utility (AFAIK).
>
> exit or _exit here would only be called if the exec fails - is that happening?
>
>
>> 2. In same code area, waitpid() was not being called on the child PID to
>> ensure
>> it had exited, thus a defunct process was being left lying around.
>
> input[read(infd[0],input,255)] = 0; // Read from child's stdout
> +
> + // Read done so waitpid on parent or will end up with defunct process
> + waitpid (manpath_pid, NULL, 0);
>
> Are you guaranteed the child will only write 255 chars or less?
> Otherwise it seems you'd deadlock here while the child waits for the parent
> to finish reading from the pipe and the parent waits for the child to exit.
Not something I (or the original coder) thought if I guess, as that part was not
written by me. Would you suggest up'ing this limit ?
> (I can't find a manpath binary on my nv_98 system to see what it outputs,
> but my current $MANPATH is 208 chars, so I could imagine if this is supposed
> to find a manpath it would be longer than that.)
>
my $MANPATH is 120 chars :)
cheers
Matt
