<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 27, 2014 at 9:48 AM, Niko Tyni <span dir="ltr"><<a href="mailto:ntyni@debian.org" target="_blank">ntyni@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tag 721421 patch<br>
thanks<br>
<span class=""><br>
On Fri, Sep 26, 2014 at 11:12:06PM +0300, Niko Tyni wrote:<br>
<br>
> The problem apparently happens when the timeout in the select loop<br>
> (one second) triggers before execvp() has been called.<br>
><br>
> I can reproduce a similar "race" on my x86_64 machine by inserting a<br>
> sleep(1) call right before the execvp() call.<br>
><br>
> I still haven't got to the bottom of it, but it looks like the gdb<br>
> output is lost somewhere with select() timeouting (and returning zero)<br>
> on subsequent calls too even though gdb has happily written to the pipe.<br>
<br>
</span>Further investigation with strace shows that the fd_set passed into<br>
select() becomes empty if execvp() happens after the first select()<br>
call. I was able to reproduce this with gdb replaced by a trivial program<br>
that just prints to stdout (which greatly helped debugging.)<br>
<br>
So I suppose the execvp() call somehow invalidates the fd set?<br>
<br>
I haven't found an explanation for this observed behaviour. The closest<br>
thing I was able to find was this in the select_tut(2) Linux manual page<br>
(on Debian sid if that matters):<br>
<br>
11. Since select() modifies its file descriptor sets, if the<br>
call is being used in a loop, then the sets must be<br>
reinitialized before each call.<br>
<br>
Reinitializing the set in the loop fixes it and seems to be the correct<br>
thing to do anyway. Patch attached, this makes it work for me on both<br>
mips and amd64.<br></blockquote><div><br></div><div>Right, that is definitely a bug. Haven't used select in such a long time that I had looked over that insanity.<br><br></div><div>Leon<br></div></div></div></div>