Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64

[Leon Timmermans]

On Sat, Sep 27, 2014 at 9:48 AM, Niko Tyni <ntyni at debian.org> wrote:

> tag 721421 patch
> thanks
>
> On Fri, Sep 26, 2014 at 11:12:06PM +0300, Niko Tyni wrote:
>
> > The problem apparently happens when the timeout in the select loop
> > (one second) triggers before execvp() has been called.
> >
> > I can reproduce a similar "race" on my x86_64 machine by inserting a
> > sleep(1) call right before the execvp() call.
> >
> > I still haven't got to the bottom of it, but it looks like the gdb
> > output is lost somewhere with select() timeouting (and returning zero)
> > on subsequent calls too even though gdb has happily written to the pipe.
>
> Further investigation with strace shows that the fd_set passed into
> select() becomes empty if execvp() happens after the first select()
> call. I was able to reproduce this with gdb replaced by a trivial program
> that just prints to stdout (which greatly helped debugging.)
>
> So I suppose the execvp() call somehow invalidates the fd set?
>
> I haven't found an explanation for this observed behaviour. The closest
> thing I was able to find was this in the select_tut(2) Linux manual page
> (on Debian sid if that matters):
>
>        11. Since  select()  modifies  its  file descriptor sets, if the
>            call is being used in a loop, then the sets must be
>            reinitialized before each call.
>
> Reinitializing the set in the loop fixes it and seems to be the correct
> thing to do anyway. Patch attached, this makes it work for me on both
> mips and amd64.
>

Right, that is definitely a bug. Haven't used select in such a long time
that I had looked over that insanity.

Leon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20140927/08860b64/attachment.html>