[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Recursive mutexes (was: Re: shutdown of listen socke

From: Christian Grothoff
Subject: Re: [libmicrohttpd] Recursive mutexes (was: Re: shutdown of listen socket does not work on solaris 10)
Date: Mon, 19 Sep 2011 14:10:15 +0200
User-agent: KMail/1.13.7 (Linux/2.6.39-1-amd64; KDE/4.6.5; x86_64; ; )

On Monday, September 19, 2011 03:00:28 AM Will Bryant wrote:
> I have a patch for this almost working on OS X, but I'm getting hangs
> running "make check" in daemontest_timeout.  My patch is causing an error,
> which I'll look into, but it's hanging because the current error handling
> code tries to recursively lock the response mutex.
> The call stack is this:
> #0  0x00007fff8ec3cbf2 in __psynch_mutexwait ()
> #1  0x00007fff8db251a1 in pthread_mutex_lock ()
> #2  0x00000001013a6ec5 in MHD_destroy_response (response=0x7ffe92000000) at
> response.c:436 #3  0x00000001013a363d in MHD_connection_close
> (connection=Cannot access memory at address 0x0 ) at connection.c:316
> #4  0x00000001013a375a in try_ready_normal_body (connection=0x7ffe92000028)
> at connection.c:337 #5  0x00000001013a15da in MHD_connection_handle_write
> (connection=0x101430d70) at connection.c:1871 #6  0x00000001013a69e9 in
> MHD_select () at daemon.c:1458
> #7  0x00000001013a6a41 in MHD_run (daemon=0x7ffe92000028) at daemon.c:1592
> #8  0x000000010139db2e in main (argc=-1845493720, argv=0x603) at
> test_callback.c:185
> It's occurring because the code does not request a recursive mutex, and
> since try_ready_normal_body is called with the mutex locked:
>           response = connection->response;
>           if (response->crc != NULL)
>             pthread_mutex_lock (&response->mutex);
>           if (MHD_YES != try_ready_normal_body (connection))
>             {
>               if (response->crc != NULL)
>                 pthread_mutex_unlock (&response->mutex);
>               break;
>             }
> when connection_close_error calls MHD_connection_close and it calls
> MHD_destroy_response, the second attempt to lock the mutex hangs.
> So should we start requesting recursive mutexes so we can be sure that
> error handling will work?  On some platforms POSIX mutexes are by default
> recursive, but POSIX says you have to ask for them to be sure.

No, definitively not.  The real fix is to not do the destroy_response where it 
is called but a bit later.  Fix is already in SVN 16954 and likely related to 
the crash reported by Regis as well...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]