On Sun, Jul 4, 2010 at 4:29 AM, Avi Bab <a...@breach.com> wrote: > > Indeed it seems that someone, some when, failed to release the lock. > At the time of the deadlock the third thread (The ReceiverThread) is > dispatching on a different eventbase. > > This third thread does do some manipulation on bufferevents that are > registered with the Sender's event_base:
[..] > > This is the only interaction with the third thread. > I do not see a relation to the deadlock. > Confusing! I don't see how this would cause the deadlock either. Have you tried configuring the lock debugging feature? Just after you call evthread_use_pthreads(), call evthread_enable_lock_debugging(): it will put wrappers around all the locks and locking callbacks to track each lock's current owner and recursion count. If there are gross errors, you'll get an assertion failure with a hopefully useful stack trace. If not, you can inspect the recursion count and owner in the debugger by casting the lock to "struct debug_lock" and looking at the count and held_by variables. [The owner is just a pthread_t as an unsigned long, as returned by pthread_self().] yrs, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
