Yeah, I had done that, thanks. Just wanted to find out if it’s just us with the issue as didn’t see anything mentioned on the list.
On 7 Aug 2014, at 22:26, Zachary Turner <[email protected]> wrote: > Ahh, I see. Can you just put an #ifdef _WIN32 that doesn't add the pipe_fd > to the fd_set for Windows? It's broken either way, but at least this way > it's less broken. > > > On Thu, Aug 7, 2014 at 2:25 PM, Deepak Panickal <[email protected]> wrote: > Yes, we have a regression in behaviour. > > Before _pipe() was added, pipes were ignored on Windows. They were not added > to the read_fds list for select(). So, the BytesAvailable() did not error. > > However, now since pipes are created, it is added to the read_fds list and > then select() fails like you said, because it is not a socket. It fails with > a WSAENOTSOCK error. Due to this, the BytesAvailable() errors out and no data > is read from the remote socket connection. > > I only found this after the merge, as we were not able to read data from our > remote debug stub. > > On 7 Aug 2014, at 22:15, Zachary Turner <[email protected]> wrote: > >> Yes, that's correct. It's just that on Windows, select() won't accept a >> pipe, it will just return an error. Which we also don't handle correctly, >> it turns out, since we assume that the error it's returning is an errno, >> which on Windows it's not. >> >> That said, I'm pretty sure ConnectionFileDescriptor has never worked on >> Windows. Are you seeing a regression in behavior? i.e. something worked >> before you merged, but now it doesn't? >> >> >> On Thu, Aug 7, 2014 at 2:06 PM, Deepak Panickal <[email protected]> wrote: >> Ah, so it is a known issue. Thanks, got it now. >> We recently did a merge which brought in the new changes from upstream. >> >> Isn’t the ::select used in ConnectionFileDescriptor to wait till input is >> available? >> Not just from the command pipe, but also from the sockets. >> >> On 7 Aug 2014, at 21:38, Zachary Turner <[email protected]> wrote: >> >>> Sorry, hit enter too soon. I have been thinking about next steps for >>> fixing this in the longer term. I think the way to go is that on Windows, >>> ConnectionFileDescriptor shouldn't even use select at all, nor should it >>> use the command pipe. The purpose of the command pipe seems to be so that >>> various interrupt commands can be sent to interrupt the select, and then >>> terminate the connection or something else so that it doesn't block forever. >>> >>> On Windows, the closest equivalent to select is WaitForMultipleObjects. So >>> I think on Windows we need to switch to using WFMO instead of select(). >>> The command pipe will be replaced by various event objects, which the user >>> will set according to which interruption command they want to send. WFMO >>> doesn't accept sockets though, so we need to call WSAEventSelect() to get >>> an event handle corresponding to read/write operations on the socket. >>> >>> There's numerous other portability issues with this class currently, most >>> notably that select() on windows doesn't set errno >>> >>> >>> On Thu, Aug 7, 2014 at 1:34 PM, Zachary Turner <[email protected]> wrote: >>> This is a known issue. But I don't think this is a regression. It's just >>> always been this way. Basically on Windows, select() only deals with >>> sockets. It doesn't work with pipes, files, or anything else. In other >>> words, ConnectionFileDescriptor is just fundamentally broken on Windows. I >>> recently pushed a large refactor to the socket logic in >>> ConnectionFileDescriptor which is aimed at addressing this. But it's only >>> one step of what I think will be a long process to get >>> ConnectionFileDescriptor working on Windows. >>> >>> >>> On Thu, Aug 7, 2014 at 1:01 PM, Deepak Panickal <[email protected]> wrote: >>> Hi, >>> >>> I have been seeing an issue with the refactored pipe support changes on >>> Windows using _pipe(). >>> >>> This is specifically at the ::select function in >>> ConnectionFileDescriptor::BytesAvailable(). >>> On Windows, the ::select fails if the pipe file descriptor is also included >>> and so the connection fails. >>> >>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ConnectionFileDescriptor.cpp?view=markup >>> >>> Wanted to ask if anybody else on Windows is seeing any such issue? >>> >>> Thanks, >>> Deepak >>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> >> > >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
