Re: [Libevent-users] deadlock in libevent-2.0.5-beta

[Zhou Li <echou327@xxxxxxxxx>]

I met such deadlock too. It happened under very high load just as you said. I think the cause is that the call write(th_notify_fd[1]) got blocked ( sorry I didn't remember the exact position of this call to write th_notify_fd).

In event.c line 2597:

    /*

      This can't be right, can it?  We want writes to this socket to

      just succeed.

      evutil_make_socket_nonblocking(base->th_notify_fd[1]);

    */

When I uncommented this block of code, the deadlock disappeared.

On Sat, Jul 3, 2010 at 1:48 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

On Thu, Jul 1, 2010 at 6:44 AM, Avi Bab <avib@xxxxxxxxxx> wrote:
>
>
> Running on Linux with pthreads.
>
>
>
> One thread (CBTcpProxyListenerThread below) adds bufferevents (with option
> BEV_OPT_THREADSAFE) to an event_base.
>
> A second thread (CBTcpProxySenderThread) dispatches on the event_base.
>
>
>

> bufferevents are removed from the event_base either by a third thread or by
> the CBTcpProxySenderThread by calling bufferevent_free (without calling
> bufferevent_disable first – is this a misuse?).
>
>
>
> The deadlock happens on pretty high load: ~6000 bufferevents are added and
> removed per second. Each one is triggered for write ~10 times per seconds
> (which gives ~60,000 triggeres per-second).


The stack traces look like they aren't the whole story.  It seems the
two threads you listed are both trying to acquire the lock for the
event base, and blocking on it..  But what's the stack of the thread
that's actually holding the lock?

--
Nick

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.