Can you try this patch? -g
poll-fix.diff
Description: Binary data
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-l...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
