[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-users] Linphone deadlock
From: |
Troy Cauble |
Subject: |
Re: [Linphone-users] Linphone deadlock |
Date: |
Wed, 07 Jul 2004 09:46:00 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 |
Matt Lawson <address@hidden> wrote:
Hello Simon (and others!),
I haven't written in a while for the simple fact that Linphone has been
working flawlessly. I haven't had to recompile it in 4 months. Until
now of course. I've run into a deadlock.
Disclaimer:
The version I have is a little bit old, so forgive me if this has been
fixed in a newer version. I compared it to 0.12.2 and the affected
portions seem to be the same. Also, I am using a custom program which
functions exactly like linphonec to issue the hangup commands (that
calls linphone_core_terminate_dialog) but is not actually linphonec.
Here's the stack trace of the two deadlocked threads:
<snipped>
I'm just not sure what the best way to fix this is. Ideas?
Matt,
I just posted about the same deadlock in the -developers list
before I saw yours in the -users list.
I'm using the osipua library but have my own code above that
instead of linphone. I still hit the deadlock because it was
natural to have a mutex at that level too. Here's what I did:
1) Went into my copy of osip and changed the smutex_init to
use PTHREAD_MUTEX_RECURSIVE_NP. (I only bothered with the
Unix with pthreads variation.)
If you don't want to touch osip, you could write smutex_init2()
and call it in osip_manager_new().
2) Changed my upper layer to point to osipua's def_manager->mutex
instead of using it's own mutex. I think this would be just a
few lines to change in linphonecore.c/h.
Maybe not the most elegant result, but it was quick.
-troy
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Linphone-users] Linphone deadlock,
Troy Cauble <=