[Home]

Summary:ASTERISK-09453: [patch] unloading res_jabber causes asterisk to segfault
Reporter:julien reveret (osiatis)Labels:
Date Opened:2007-05-16 04:18:38Date Closed:2007-07-11 19:59:21
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Resources/res_jabber
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) branch-1.4-bug_9738-3.diff
( 1) bt.txt
( 2) bt-full.txt
( 3) iksemel_1.2-tls_socket_timeout-1.diff
Description:I am testing asterisk jabber client. Everytime I try to unload the res_jabber.so module, Asterisk segfaults :

[May 16 10:59:08] VERBOSE[21962] logger.c:   == Unregistered application 'JabberSend'
[May 16 10:59:08] VERBOSE[21962] logger.c:   == Unregistered application 'JabberStatus'
[May 16 10:59:08] VERBOSE[21962] logger.c:   == Manager unregistered action JabberSend
Segmentation fault
Comments:By: Joshua C. Colp (jcolp) 2007-05-16 12:21:48

Are you unloading chan_gtalk.so / chan_jingle.so before unloading res_jabber.so or not?
By: julien reveret (osiatis) 2007-05-21 02:19:30

I was just unloading res_jabber.so, I then tried unloading chan_gtalk and chan_jingle before unloading res_jabber, but asterisk still segfaults :
*CLI> module unload chan_gtalk.so
*CLI>   == Unregistered channel type 'Gtalk'
*CLI> module unload chan_jingle.so
*CLI>   == Unregistered channel type 'Jingle'
*CLI> module unload res_jabber.so
*CLI>   == Unregistered application 'JabberSend'
 == Unregistered application 'JabberStatus'
 == Manager unregistered action JabberSend
Segmentation fault
By: Jason Parker (jparker) 2007-05-24 09:45:32

Can you please upload a backtrace, per bug reporting guidelines?
By: Eliel Sardanons (eliel) 2007-05-31 20:13:23

The problem (I think) is when doing: iks_disconnect(client->p);
on the function: ast_aji_disconnect()

I have commented this code and I couldn't reproduce the crash.
By: phsultan (phsultan) 2007-06-01 19:36:50

On my system, the 'module unload res_jabber.so' CLI command yields different problems depending on the configuration.

I'm experiencing a crash when the Asterisk - Jabber server connection is not secured with TLS. When the connection is secured, Asterisk hangs and must be killed.

This bug puts in evidence a design flaw in the iksemel library. The 'iks_recv' function ignores the timeout parameter if the underlying connection is secured with TLS. The recv call does not return upon timeout expiration, whereas it does if the connection is not secured.

This problem is described on this thread taken from the iksemel-dev mailing list : http://mail.jabber.org/pipermail/iksemel-dev/2005-October/000728.html
I attach a patch to the iksemel 1.2 library that solves this issue, by following Darrell Karbott's advices available in the mentioned thread.

Another patch to Asterisk is attached (branch-1.4-bug_9738-1.diff) in order to explictly end each client's thread when unloading res_jabber.so.

Both patches are needed to correct the issues observed on my system. Please give your feedback, thanks !

Philippe
By: phsultan (phsultan) 2007-06-01 19:43:03

Disclaimer is on file.
By: jmls (jmls) 2007-06-02 04:53:34

is this related to ASTERISK-7963 ?
By: phsultan (phsultan) 2007-06-02 18:42:13

Hi Julian,

it appears indeed that both bugs address the same issue. As mentioned in ASTERISK-7963, there is a problem inside the iksemel library, which I hope to have fixed with the attached patch.
By: phsultan (phsultan) 2007-06-04 08:16:22

New patch adds a rough locking mechanism to handle the different modifications of the data->timeout variable within the iksemel library, caused by calls to iks_recv.
By: phsultan (phsultan) 2007-06-05 04:39:01

Hans, as you've been working on the TLS problems with iksemel, I thought you might be interested in this bug report, too :)
By: phsultan (phsultan) 2007-06-06 12:24:47

The previous locking mechanism made more harm than good, because it relied on the jabber client's lock.

I tried to separate things a little in new patch in branch-1.4-bug_9738-3.diff :
- added a local mutex
- all calls to the iks_recv function are wrapped in aji_iks_recv

Please test along with the patched iksemel library :)
By: Olle Johansson (oej) 2007-06-07 04:01:34

Committed patch without the locking to 1.4 rev 67993 and trunk. Thanks for the patch, Philippe.

We need to investigate the locking a bit further to see how that can be done without risking deadlocks as well as if there's a solution without having to maintain a patch to iksemel.
By: Olle Johansson (oej) 2007-06-07 04:47:48

Ok, after discussing this for a while, Philippe and I decided to disable unloading the module when you have TLS connections. Shutdown will still work, but "module unload" will refuse.  It is not a good solution, but will prevent a crash.

Longterm, I think we have to stop using the TCP/TLS functions in iksemel and only use the parsing part of the iksemel library. That will remove the need for the GNUTLS library.
By: Jason Parker (jparker) 2007-06-20 14:06:25

I'm going to go ahead and close this, since the change that went in did fix the initial problem.  Issue ASTERISK-9675 will get rid of this problem long-term.