No problem, I'll do it later todya.
On Thu, Aug 7, 2014 at 2:38 PM, Deepak Panickal <[email protected]> wrote: > Could you please make the change, I am not at my work machine now. > Or I can fix it tomorrow. > > Thanks! > > On 7 Aug 2014, at 22:34, Zachary Turner <[email protected]> wrote: > > No worries. Do you want to commit that fix by itself, or should I? > > > On Thu, Aug 7, 2014 at 2:30 PM, Deepak Panickal <[email protected]> > wrote: > >> 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
