Hi Benny, Is it a lot of code rewriting to make it do the right thing? On Sat, May 26, 2012 at 11:43:37AM +0700, Benny Prijono wrote: > 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 > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120526/1f7f107f/attachment.bin>