Hi David,
That may be correct, but I think it's likely that the mutex owner in this
case is the calling mutex itself. It's unfortunate that it has been in our
coding style to acquire the mutex for an object before we destroy that
object. And in this case, if you look at our pj_mutex_destroy() function in
os_core_unix.c, you see that we will do some retries when the destroy fails
with EBUSY.
Best regards,
Benny
On Sat, May 26, 2012 at 1:08 AM, David Hill <dhill at mindcry.org> wrote:
> Hello,
>
> I am running pjsua 1.14.2 on OpenBSD.
>
> OpenBSD pthreads (rthreads) has a debugging statement in its
> pthread_mutex_destroy function to let you know if pthread_mutex_destroy
> is called with waiters.
>
> int
> pthread_mutex_destroy(pthread_mutex_t *mutexp)
> {
> struct pthread_mutex *mutex;
>
> assert(mutexp);
> mutex = (struct pthread_mutex *)*mutexp;
> if (mutex) {
> if (mutex->count || mutex->owner != NULL ||
> !TAILQ_EMPTY(&mutex->lockers)) {
> #define MSG "pthread_mutex_destroy on mutex with waiters!\n"
> write(2, MSG, sizeof(MSG) - 1);
> #undef MSG
> return (EBUSY);
> }
> free(mutex);
> *mutexp = NULL;
> }
> return (0);
> }
>
> Running pjsua, my screen is spammed with "pthread_mutex_destroy on mutex
> with waiters!" every couple of seconds. I think pj_mutex_destroy is
> being called too early here...
>
> I have provided a backtrace from GDB.
>
> (gdb) bt
> #0 pj_mutex_destroy (mutex=0x7c1283b8) at ../src/pj/os_core_unix.c:1350
> #1 0x1c04bb18 in pjsip_tx_data_dec_ref (tdata=0x7c128064) at
> ../src/pjsip/sip_transport.c:446
> #2 0x1c056050 in tsx_destroy (tsx=0x7c12a864) at
> ../src/pjsip/sip_transaction.c:1040
> #3 0x1c0564be in tsx_set_state (tsx=0x7c12a864,
> state=PJSIP_TSX_STATE_DESTROYED, event_src_type=PJSIP_EVENT_TIMER,
> event_src=0x7c12a974)
> at ../src/pjsip/sip_transaction.c:1204
> #4 0x1c05656b in tsx_on_state_terminated (tsx=0x7c12a864,
> event=0x7c11eed4) at ../src/pjsip/sip_transaction.c:3228
> #5 0x1c055f6c in tsx_timer_callback (theap=0x7c06d1f8, entry=0x7c12a974)
> at ../src/pjsip/sip_transaction.c:1107
> #6 0x1c0ccc7f in pj_timer_heap_poll (ht=0x7c06d1f8,
> next_delay=0x7c11ef70) at ../src/pj/timer.c:518
> #7 0x1c045d02 in pjsip_endpt_handle_events2 (endpt=0x7c06d064,
> max_timeout=0x7c11efa4, p_count=0x7c11efac) at
> ../src/pjsip/sip_endpoint.c:708
> #8 0x1c01aa1e in pjsua_handle_events (msec_timeout=10) at
> ../src/pjsua-lib/pjsua_core.c:1550
> #9 0x1c01aa84 in worker_thread (arg=0x0) at
> ../src/pjsua-lib/pjsua_core.c:571
> #10 0x1c0bf5d7 in thread_main (param=0x7c0dbfc0) at
> ../src/pj/os_core_unix.c:512
> #11 0x03a09c2e in _rthread_start (v=0x7c086600) at
> /usr/src/lib/librthread/rthread.c:113
> #12 0x0f138313 in __tfork_thread () from /usr/lib/libc.so.64.0
>
> - David
>
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120526/aad8ad4a/attachment.html>
