On Thu, Jan 14, 2016 at 09:47:37AM +0000, Dimitris Papastamos wrote:
> On Thu, Jan 14, 2016 at 09:02:43PM +1300, David Phillips wrote:
> > The child thread was created because execlp will not return if successful.
> > The eprintf was placed after the call to execlp to catch any error, but the
> > child continued to return a (closed) fds[0], resulting in a second slideshow
> > being run by the child.
> >
> > This commit fixes the issue by killing the child.
> > ---
> > sent.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sent.c b/sent.c
> > index fc5e389..88abe90 100644
> > --- a/sent.c
> > +++ b/sent.c
> > _AT_@ -153,7 +153,7 @@ filter(int fd, const char *cmd)
> > close(fds[0]);
> > close(fds[1]);
> > execlp(cmd, cmd, (char *)0);
> > - eprintf("execlp %s:", cmd);
> > + die("execlp %s:", cmd);
> > }
> > close(fds[1]);
> > return fds[0];
> > --
> > 2.6.2
> >
>
> I should mention there are many more places in the code where this
> issue happens.
You are probably right, but this one was the most annoying one to try and
understand the cause of up until the penny finally dropped.
> On BSD there is err() and warn() which makes it very clear which one
> is fatal.
>
> One approach is to keep die() and rename eprintf() to something more
> appropriate.
>
> Otherwise we can use the approach in sbase which is to have eprintf()
> be equivalent to die() and weprintf() for just the warning version.
>
I will submit a patch to this effect shortly and see what others make of it.
Cheers
Received on Wed Jan 20 2016 - 08:10:17 CET