headers
Norman Franke | 19 Aug 18:42
Favicon

Possible Deadlock?

I had a deadlock today using 1.4.21.1. I had asterisk dump core to  
explore in GDB. Thread 32 is waiting for the "channels" lock held by  
21 while holding a channel lock. Thread 21 is then waiting for a lock  
on a channel held by 32 while holding a lock on "channels".

However, I can't figure out how thread 32 got the lock in the first  
place. Perhaps from this in the log?

[Aug 19 10:55:26] VERBOSE[25324] logger.c:     -- Got SIP response 480  
"Temporarily Unavailable" back from 172.16.22.30

And it never released the lock? I see in chan_sip.c:12936

                                 /* XXX Locking issues?? XXX */

This has only happened once recently.

Thread 32 (process 25324):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7edd56e in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/ 
libpthread.so.0
#2  0xb7eda179 in _L_mutex_lock_141 () from /lib/tls/i686/cmov/ 
libpthread.so.0
#3  0xb786a918 in ?? ()
#4  0x0807d514 in ast_cdr_start (cdr=0x815a148) at cdr.c:689
#5  0x0807fd3f in ast_mutex_lock (pmutex=0x815a148) at /usr/src/ 
asterisk-1.4.21.1/include/asterisk/lock.h:755
#6  0x08081795 in ast_channel_alloc (needqueue=0, state=0,  
cid_num=0xb7358a4d "6106421787", cid_name=0x8150810 "",
     acctcode=0x8150810 "", exten=0xb7358a05 "8827",
(Continue reading)

Permalink | Reply |
headers
Moises Silva | 19 Aug 19:20

Re: Possible Deadlock?

If I were you, I'd compile Asterisk with DEBUG_CHANNEL_LOCKS,
reproduce the issue and execute command "core show locks", this will
likely be easier to debug.

Moy

On Tue, Aug 19, 2008 at 11:46 AM, Norman Franke <norman <at> myasd.com> wrote:
> I had a deadlock today using 1.4.21.1. I had asterisk dump core to
> explore in GDB. Thread 32 is waiting for the "channels" lock held by
> 21 while holding a channel lock. Thread 21 is then waiting for a lock
> on a channel held by 32 while holding a lock on "channels".
>
> However, I can't figure out how thread 32 got the lock in the first
> place. Perhaps from this in the log?
>
> [Aug 19 10:55:26] VERBOSE[25324] logger.c:     -- Got SIP response 480
> "Temporarily Unavailable" back from 172.16.22.30
>
> And it never released the lock? I see in chan_sip.c:12936
>
>                                 /* XXX Locking issues?? XXX */
>
> This has only happened once recently.
>
> Thread 32 (process 25324):
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xb7edd56e in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/
> libpthread.so.0
> #2  0xb7eda179 in _L_mutex_lock_141 () from /lib/tls/i686/cmov/
> libpthread.so.0
(Continue reading)

Permalink | Reply |
headers
Russell Bryant | 19 Aug 19:25

Re: Possible Deadlock?

Moises Silva wrote:
> If I were you, I'd compile Asterisk with DEBUG_CHANNEL_LOCKS,
> reproduce the issue and execute command "core show locks", this will
> likely be easier to debug.

Minor correction: DEBUG_THREADS, not DEBUG_CHANNEL_LOCKS

--

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply |
headers
Ruddy Gbaguidi | 19 Aug 20:24

res_jabber call backs

Hi all,
As I see, in the asterisk 1.4, jabber is designed to send messages, 
receive answers and display them in the cli.
I think we should add the feature that any asterisk module can register 
some callbacks for a specific jabber user.
Then, from any module, we can request the client using his username and 
register callbacks on message, on presence etc...
So, as soon as a message will be receive, the call back will be fire.

What do you think about that ?

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply |
headers
John Todd | 21 Aug 18:07

Re: res_jabber call backs

At 2:24 PM -0400 2008/8/19, Ruddy Gbaguidi wrote:
>
>Hi all,
>As I see, in the asterisk 1.4, jabber is designed to send messages,
>receive answers and display them in the cli.
>I think we should add the feature that any asterisk module can register
>some callbacks for a specific jabber user.
>Then, from any module, we can request the client using his username and
>register callbacks on message, on presence etc...
>So, as soon as a message will be receive, the call back will be fire.
>
>What do you think about that ?

I believe there is some work being done on Asterisk receiving 
messages and processing them, but perhaps not exactly what you're 
looking for (yet?)  Maybe you could add those features for presence 
or event callback.  It sounds like you're talking about using XMPP as 
an API - or am I misunderstanding your question?

As a side note, take a look here at the work that Philippe Sultan is doing:

  http://svn.digium.com/view/asterisk/team/phsultan/jabberreceive/

  http://lists.digium.com/pipermail/asterisk-users/2008-June/213525.html

This is _really_ interesting stuff, and creative use of XMPP combined 
with Asterisk should allow all sorts of IM-based call transactions. 
I'd encourage anyone with interest in UC work to take a look at this 
branch, test the apps, and report your results so this can be merged 
into mainline if it seems stable and worthwhile.
(Continue reading)

Permalink | Reply |
headers
BJ Weschke | 21 Aug 20:47

Re: res_jabber call backs

John Todd wrote:
> At 2:24 PM -0400 2008/8/19, Ruddy Gbaguidi wrote:
>   
>> Hi all,
>> As I see, in the asterisk 1.4, jabber is designed to send messages,
>> receive answers and display them in the cli.
>> I think we should add the feature that any asterisk module can register
>> some callbacks for a specific jabber user.
>> Then, from any module, we can request the client using his username and
>> register callbacks on message, on presence etc...
>> So, as soon as a message will be receive, the call back will be fire.
>>
>> What do you think about that ?
>>     
>
> I believe there is some work being done on Asterisk receiving 
> messages and processing them, but perhaps not exactly what you're 
> looking for (yet?)  Maybe you could add those features for presence 
> or event callback.  It sounds like you're talking about using XMPP as 
> an API - or am I misunderstanding your question?
>
>
> As a side note, take a look here at the work that Philippe Sultan is doing:
>
>   http://svn.digium.com/view/asterisk/team/phsultan/jabberreceive/
>
>   http://lists.digium.com/pipermail/asterisk-users/2008-June/213525.html
>
> This is _really_ interesting stuff, and creative use of XMPP combined 
> with Asterisk should allow all sorts of IM-based call transactions.
(Continue reading)

Permalink | Reply |
headers
Ruddy Gbaguidi | 22 Aug 02:05

Re: res_jabber call backs


Yes, it may become a very good feature if asterisk can receive
at any given time a message, parse it and execute something.
That will allow an asterisk server to be part of any existing jabber 
network and interact more easily with other process like IM clients or 
embedded IM clients.

John Todd wrote:
> At 2:24 PM -0400 2008/8/19, Ruddy Gbaguidi wrote:
>   
>> Hi all,
>> As I see, in the asterisk 1.4, jabber is designed to send messages,
>> receive answers and display them in the cli.
>> I think we should add the feature that any asterisk module can register
>> some callbacks for a specific jabber user.
>> Then, from any module, we can request the client using his username and
>> register callbacks on message, on presence etc...
>> So, as soon as a message will be receive, the call back will be fire.
>>
>> What do you think about that ?
>>     
>
> I believe there is some work being done on Asterisk receiving 
> messages and processing them, but perhaps not exactly what you're 
> looking for (yet?)  Maybe you could add those features for presence 
> or event callback.  It sounds like you're talking about using XMPP as 
> an API - or am I misunderstanding your question?
>
>
> As a side note, take a look here at the work that Philippe Sultan is doing:
(Continue reading)

Permalink | Reply |
headers
Moises Silva | 20 Aug 00:30

Re: Possible Deadlock?

> Minor correction: DEBUG_THREADS, not DEBUG_CHANNEL_LOCKS

oops, sorry about that, Russell is correct, DEBUG_THREADS is the
required option to compile with "core show channels" support. Select
it by doing:

make menuselect

10. Compiler Options -> 3. DEBUG_THREADS

Moy

--

-- 
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply |
headers
Mark Michelson | 22 Aug 18:31
Gravatar

Re: Possible Deadlock?

Norman Franke wrote:
> I had a deadlock today using 1.4.21.1. I had asterisk dump core to  
> explore in GDB. Thread 32 is waiting for the "channels" lock held by  
> 21 while holding a channel lock. Thread 21 is then waiting for a lock  
> on a channel held by 32 while holding a lock on "channels".
> 
> However, I can't figure out how thread 32 got the lock in the first  
> place. Perhaps from this in the log?
> 
> [Aug 19 10:55:26] VERBOSE[25324] logger.c:     -- Got SIP response 480  
> "Temporarily Unavailable" back from 172.16.22.30
> 
> And it never released the lock? I see in chan_sip.c:12936
> 
>                                  /* XXX Locking issues?? XXX */
> 
> This has only happened once recently.
> 
> Thread 32 (process 25324):
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xb7edd56e in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/ 
> libpthread.so.0
> #2  0xb7eda179 in _L_mutex_lock_141 () from /lib/tls/i686/cmov/ 
> libpthread.so.0
> #3  0xb786a918 in ?? ()
> #4  0x0807d514 in ast_cdr_start (cdr=0x815a148) at cdr.c:689
> #5  0x0807fd3f in ast_mutex_lock (pmutex=0x815a148) at /usr/src/ 
> asterisk-1.4.21.1/include/asterisk/lock.h:755
> #6  0x08081795 in ast_channel_alloc (needqueue=0, state=0,  
> cid_num=0xb7358a4d "6106421787", cid_name=0x8150810 "",
(Continue reading)

Permalink | Reply |

Gmane