Fix off-by-one in NextFreeFileDescriptor

[okayzed]

https://github.com/oilshell/oil/blob/master/core/process.py#L54

If i'm understanding this code correctly, the intended behavior is: loop over file descriptors until we find one that throws an error when we try to access it. when we find it, we return that filedescriptor.

The actual behavior: return that filedescriptor+1

This could come up as a problem if we load 2 file descriptors then close the first one. the impl would find the first one as available and then try to dup over the 2nd one.

Feel free to close if not an issue

[andychu]

Hm yes good point. That explains the comment...

The bug was that other libraries in the process were using file descriptors. So this fix was wrong. But I fixed it another way by not using those libraries (import random). But yes this function should probably be fixed just in case.

[andychu]

And that was the "hardest bug" I mentioned in the appendix here:

http://www.oilshell.org/blog/2018/10/11.html

I already hit that bug twice!

[okayzed]

If you can add a test case (or put one here) that repros the filedescriptor bug, it will make it easier to fix

[andychu]

I don't think this issue is observable right now. If nobody else is opening file descriptors in the process, there's no conflict.

But I'll just leave this open since it's probably a good cleanup.

[okayzed]

It might not get fixed properly without a repro or way of checking that it's fixed, even if this line of code is fixed. It's easy enough to change this seemingly wrong line, but unknown if that was causing issues in the first place

[andychu]

@okayzed

Oh man I'm in the middle of debugging a problem here and the root cause was in this code. The observable behavior was that somehow stdout was closed when running OSH unit tests under OSH, but not when running OSH unit tests under bash!

I think there are probably other conditions where it could trigger, but OSH inheriting its own file descriptors seems to be one of them.

I have made the bug go away by fixing this line, but it also pointed to me the fact that I'm using the syscalls somewhat wrong.

If you look at man fcntl, it points out that fcntl(..., F_DUPFD, ...) is different than dup2(). I was wondering what the difference was. Basically the former does the linear search for you -- it returns the next free descriptor. I was doing it in user space, which is suboptimal (and was wrong).

Good eye on this one!

In retrospect, it may or may not have made sense to fix earlier... it would have saved some time, but I probably wouldn't have understood the syscall issue as deeply. Sometimes you just have to bang your head into things to understand ...

[okayzed]

I'm glad something came of this!

re: fcntl: to clarify for my own understanding, it seems like using dup2 can lead to some race condition, where you check if a FD is available and it gets taken before you use it (if there is multithreading), while fcntl would prevent that situation

actually, i'm unsure of the above. if dup2 is returning the error, that would mean that the call to dup2 is what reserves the FD slot.

[andychu]

If there were two threads doing that at the same time, it would definitely lead to a race condition. But almost all shells are single-threaded, since they date back to the time before threads!

There is one area where I might want to use threads (to make completion responsive against slow user plugins), so that is something to watch out for.

[andychu]

closing in favor of #223