<div dir="ltr">I've bumped SRCREV to include your latest fix and re-enabled epoll and now it doesn't get stuck for me, thanks!<div><br></div><div>I did quick check for UID/GID issue:</div><div><a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434">https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434</a><br></div><div><br></div><div>without epoll disabled and SRCREV "b6a015a Handle O_TMPFILE more better" it was still reproducible, now I'm testing with epoll enabled and latest SRCREV "f3f4459 Epoll: use the correct client"</div><div><br></div><div>Regards,</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 19, 2018 at 6:55 PM, Seebs <span dir="ltr"><<a href="mailto:seebs@seebs.net" target="_blank">seebs@seebs.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 19 Feb 2018 11:27:56 +0200<br>
Alexander Kanavin <<a href="mailto:alexander.kanavin@linux.intel.com">alexander.kanavin@linux.<wbr>intel.com</a>> wrote:<br>
<br>
> > Huh. It's possible that the initial "don't try to close fd 0" was<br>
> > correct, and the real problem is that the attempt is getting made<br>
> > mistakenly. I'll study that more; the epoll code was a contribution<br>
> > and I may not have fully understood it.<br>
><br>
> To be honest, it would have been better to apply my epoll patch as it<br>
> is, and then do additional modifications as separate commits. That<br>
> would make it simpler to isolate the issue. We've used my epoll patch<br>
> for many months without problems on the autobuilder and elsewhere.<br>
<br>
</span>... Wow, you know, now that you *mention* it, that is a really good<br>
idea. *sigh* Sorry about that.<br>
<br>
Hmm.<br>
<span class=""><br>
> if (clients[events[i].data.u64].<wbr>fd == listen_fd) {<br>
<br>
</span>Just a sanity-check: Should this be equivalent to:<br>
if (events[[i].data.u64 == 0)<br>
?<br>
<br>
The reason I ask is that, looking at the code, we should never, ever,<br>
be getting into close_client(0). The "<=" check was right.<br>
<br>
The only call to close_client anywhere in the epoll case is:<br>
<br>
> } else {<br>
> int n = 0;<br>
> ioctl(clients[i].fd, FIONREAD, &n);<br>
> if (n == 0) {<br>
> close_client(i);<br>
> } else {<br>
> serve_client(i);<br>
> }<br>
<br>
And that's the else for clients... oh hey<br>
<span class=""><br>
<br>
> if (clients[events[i].data.u64].<wbr>fd == listen_fd) {<br>
</span>...<br>
> ioctl(clients[i].fd, FIONREAD, &n);<br>
<br>
do you see the error? I do.<br>
<br>
This gets back to "and one of the problems with testing is that<br>
if I don't actually check the logs, I often don't see problems",<br>
because pseudo does enough internal disaster recovery that things can<br>
explode horribly without observable failures.<br>
<br>
Now extracting the data.u64 value and using that consistently as the<br>
index. Pushed fix to master.<br>
<span class="HOEnZb"><font color="#888888"><br>
-s<br>
</font></span></blockquote></div><br></div>