[Home]

Summary:ASTERISK-26586: chan_sip: Segfaults upon reload if client with MWI wasn't registered
Reporter:Michael Kuron (mkuron)Labels:
Date Opened:2016-11-12 04:39:47.000-0600Date Closed:2016-11-30 07:57:17.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:13.12.2 Frequency of
Occurrence
Frequent
Related
Issues:
Environment:Debian 8 i686Attachments:( 0) bt1.txt
( 1) bt2.txt
( 2) btfull.txt
( 3) extensions.conf
( 4) logger.conf
( 5) modules.conf
( 6) sip.conf
( 7) voicemail.conf
Description:The following leads to a segfault in Asterisk 13. I have never observed this problem in Asterisk 11. However, judging from the backtrace, it is possible that ASTERISK-25747 is the same issue.

# A client registers to Asterisk via TCP. Its IP address etc. get written to astdb at _/SIP/Registry/clientname_.
At this point, {{sip show tcp}} shows an entry like {{192.168.200.144:61019 TCP Server}}.
# I restart Asterisk or issue the commands {{module unload chan_sip}} and {{module load chan_sip}}.
After this, {{sip show tcp}} will show a bogus entry like {{192.168.200.144:61019 TCP Client}} because, while loading the SIP configuration, Asterisk reads the client's last IP/port from astdb and attempts to send an MWI to it (see bt1.txt).
If the client rejects that connection, everything is ok and the line disappears from {{sip show tcp}} again. However, if the client silently discards the connection (e.g. due to firewall settings), we have a problem in step 3b.
# (a) If the client re-registers with Asterisk, the line in {{sip show tcp}} is replaced with a correct one like {{192.168.200.144:61020 TCP Server}}. (b) If, however, I run {{module unload chan_sip}} before the client re-registers, i.e. while {{192.168.200.144:61019 TCP Client}} is still there, Asterisk attempts to kill the TCP thread, which was never set up. This leads to a segfault (see bt2.txt).

I have attached a minimal configuration that reproduces the issue. Note that not all clients trigger it. Snom phones, for example, reject the connection in step 2 and the problem doesn't occur. A Gigaset N510 on the other hand silently discards the connection, which triggers the problem. If you disconnect the client from the network before Asterisk tries to make the connection, you can probably trigger it with any client as the connection will never be accepted or rejected.
Comments:By: Asterisk Team (asteriskteam) 2016-11-12 04:39:48.512-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Rusty Newton (rnewton) 2016-11-13 09:25:33.801-0600

Thanks for the very thorough report. Can you also grab another backtrace with bt full and thread apply all:
{noformat}
gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c core > /tmp/backtrace.txt
{noformat}

By: Michael Kuron (mkuron) 2016-11-13 09:49:31.745-0600

Here's the backtrace you requested.

By: Friendly Automation (friendly-automation) 2016-11-30 07:57:18.813-0600

Change 4494 merged by zuul:
chan_sip: Fix segfault during module unload

[https://gerrit.asterisk.org/4494|https://gerrit.asterisk.org/4494]

By: Friendly Automation (friendly-automation) 2016-11-30 08:14:28.944-0600

Change 4495 merged by Joshua Colp:
chan_sip: Fix segfault during module unload

[https://gerrit.asterisk.org/4495|https://gerrit.asterisk.org/4495]

By: Friendly Automation (friendly-automation) 2016-11-30 09:22:07.506-0600

Change 4496 merged by Joshua Colp:
chan_sip: Fix segfault during module unload

[https://gerrit.asterisk.org/4496|https://gerrit.asterisk.org/4496]

By: Friendly Automation (friendly-automation) 2016-12-19 16:12:17.256-0600

Change 4615 merged by Joshua Colp:
chan_sip: Reorder unload_module to deal with stuck TCP threads.

[https://gerrit.asterisk.org/4615|https://gerrit.asterisk.org/4615]

By: Friendly Automation (friendly-automation) 2016-12-19 16:19:51.152-0600

Change 4640 merged by Joshua Colp:
chan_sip: Reorder unload_module to deal with stuck TCP threads.

[https://gerrit.asterisk.org/4640|https://gerrit.asterisk.org/4640]

By: Friendly Automation (friendly-automation) 2016-12-19 17:24:36.314-0600

Change 4641 merged by Joshua Colp:
chan_sip: Reorder unload_module to deal with stuck TCP threads.

[https://gerrit.asterisk.org/4641|https://gerrit.asterisk.org/4641]