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>
