[Mono-dev] _wapi_connect stuck in poll()

[yoni shalom]

Will this be committed to trunk / 2.4.x LTS branch ?

On Sun, May 30, 2010 at 7:48 PM, yoni shalom <silver83 at gmail.com> wrote:
> Edited the patch to aligned with 2.4.2.3 source code (which I'm
> compiling from), and attached.
> Patch seems to fix it, thanks. (sorry for the double-send -g)
>
> Yoni Shalom.
>
> On Tue, May 25, 2010 at 10:15 PM, Geoff Norton <gnorton at novell.com> wrote:
>> Can you try this patch?
>>
>> -g
>>
>>
>> On 2010-05-25, at 3:05 PM, yoni shalom wrote:
>>
>>> Tested on Mono 2.4.2.3, 2.6.x
>>> Both leopard and snow leopard.
>>>
>>> It seems as though _sometime_ (ranges from 0 to 5 out of 50) threads
>>> that are in the middle of performing Socket.Connect() on which
>>> Thread.Abort() is called, never exit and cause the thread to "leak"
>>> and be stuck indefinitely.
>>>
>>> The offending thread is stuck in
>>> Socket.Connect()->Connect_internal->_wapi_connect->poll().
>>> I'm attaching a test program - just let it run, wait for 30 seconds
>>> and then in gdb display all stacks ( t apply all bt ) and you will see
>>> the threads stuck in ves_blabla_Connect_Internal()
>>>
>>> The code I'm talking about is this (mono/io-layer/sockets.c) :
>>>
>>> while (poll (&fds, 1, -1) ==  -1 &&
>>>           !_wapi_thread_cur_apc_pending ()) {
>>>      if (errno != EINTR) {
>>>        errnum = errno_to_WSA (errno, __func__);
>>>
>>> #ifdef DEBUG
>>>        g_message ("%s: connect poll error: %s",
>>>             __func__, strerror (errno));
>>> #endif
>>>
>>>        WSASetLastError (errnum);
>>>        return(SOCKET_ERROR);
>>>      }
>>> }
>>>
>>> I've been trying to debug this code without much luck understanding
>>> what is special to the misbehaving scenario...
>>>
>>> A change in the first line of code, allowing for a timeout of 3
>>> seconds in the poll syscall (not sure how correct this is), seems to
>>> solve the problem for me.
>>> int prslt;
>>> while(((prslt = poll(&fds, 1, 3000)) == 0) || (prslt == -1 &&
>>>         !_wapi_thread_cur_apc_pending()) {
>>> .......
>>>
>>>
>>> Obviously this is not optimal, and as such - is not a solution
>>> proposal but just additional info.
>>> <BeginConnect.zip>_______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>