[lldb-dev] Pipe issue on LLDB Windows?

[Zachary Turner]

No problem, I'll do it later todya.


On Thu, Aug 7, 2014 at 2:38 PM, Deepak Panickal <deepak at codeplay.com> 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 <zturner at google.com> 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 <deepak at codeplay.com>
> 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 <zturner at google.com> 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 <deepak at codeplay.com>
>> 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 <zturner at google.com> 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 <deepak at codeplay.com>
>>> 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 <zturner at google.com> 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 <zturner at google.com>
>>>> 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 <deepak at codeplay.com>
>>>>> 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
>>>>>> lldb-dev at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140807/dc178971/attachment.html>