-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segfault using socket.fdopen() + connect #6
Comments
Using undocumented APIs? ;) It would have crashed when calling :connect on a socket pair, too, though. Calling :connect doesn't make sense in either case because the object doesn't know what the host address is. The patch I committed will return an error when :connect is called and there's no host information available. By the way, socket.fdopen duplicates the descriptor, so it doesn't need to be explicitly discarded. The above code leaks rawfd. I'll accept a patch that adds an option to tell .fdopen to take ownership of the existing descriptor number. But because stale descriptors are perhaps the biggest source of bugs in asynchronous networking software, I prefer that the default behavior is to duplicate the descriptor. |
Doesn't it? IIRC, at the syscall level, you're meant to call
Can I tell it somehow? Or could it just do without it?
Yeah I thought so; but when filing a bug it's better to never clean up at all than to clean up too early :) |
Btw, with the fix from bb0181e I just see |
connect(2) requires passing the connect address, which is unknown when using socket.fdopen. There's no way at the moment to wrap an existing socket descriptor and then call :connect. The way .fdopen is meant to work, the socket should already be in the connected state. If it's already in the connected state there's no need to call :connect--:read and :write should just work. What's your use case? You might be able to fake waiting for the connection to finish by doing cqueues.poll{ .pollfd = sock:pollfd(), .events = "w" }. The .fdopen API could be changed, or I could test out one of several ugly hacks that come to mind, but it seems like a really weird case: if you know the address, just call socket.connect("127.0.0.1", 80); if you already have a descriptor where connect has already been called, then why can't the connect be finished? (Maybe originally you just wanted to wrap a descriptor and then have cqueues start and finish the connect?) FWIW, I recently added a feature which short-circuited some of the DNS resolver code when an IP address was specified. Previously a connect would fail for "127.0.0.1" if, e.g., /etc/resolv.conf was missing. Now address literals should work even when a host name couldn't be resolved. The "Unknown error" is a bug in my makefile. It's not rebuilding errno.o when lib/socket.h changes. Try |
I'm trying to rewrite the
That's what I've been doing in the mean time :) If it's correct, maybe
Ah ha! thanks. |
Is that just marking the segfault as fixed? |
I was just marking the segfault as fixed. Making socket:connect work after .fdopen would be much more involved. If you really need it please open a new ticket. I'm not sure, yet, how to address it. The pattern doesn't fit well with the low-level socket library abstraction. |
On my computer, the following program consistently segfaults:
The text was updated successfully, but these errors were encountered: