[asterisk-bugs] [JIRA] (ASTERISK-21806) Segfault in CHAN_SIP - in _int_malloc while in __ast_cc_config_params_init

[Rusty Newton (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207378#comment-207378 ] 

Rusty Newton edited comment on ASTERISK-21806 at 6/20/13 3:16 PM:
------------------------------------------------------------------

Thanks for the update.

1. If possible, test with the latest SVN snapshot of the 1.8 branch to see if the issue has already been fixed.

2. With your current version, or preferably with the latest SVN checkout of 1.8, Collect an Asterisk VERBOSE and DEBUG log during the issue occurring (plugging in the gateway and it attempting registrations). See https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information for more info. Be sure you have them both set to level 5 and you might as well turn on "sip set debug on" as well.

3. At the same time, begin a tcpdump/wireshark capture to get all RTP/SIP traffic to capture during reproduction.

4. provide your sip.conf with private info sanitized.

5. full backtrace from the core generated in the crash with the steps above.

6. If you can, recompile with DEBUG_THREADS and BETTER_BACKTRACES, then also get the "core show locks" and a full backtrace [while asterisk is running|https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock] when it's unresponsive.

That should be enough info for a developer to look further into it.

                
      was (Author: rnewton):
    Thanks for the update.

1. If possible, test with the latest SVN snapshot of the 1.8 branch to see if the issue has already been fixed.

2. With your current version, or preferably with the latest SVN checkout of 1.8, Collect an Asterisk VERBOSE and DEBUG log during the issue occurring (plugging in the gateway and it attempting registrations). See https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information for more info. Be sure you have them both set to level 5 and you might as well turn on "sip set debug on" as well.

3. At the same time, begin a tcpdump/wireshark capture to get all RTP/SIP traffic to capture during reproduction.

4. provide your sip.conf with private info sanitized.

5. If you can, recompile with DEBUG_THREADS and BETTER_BACKTRACES, then also get the "core show locks" and a full backtrace [while asterisk is running|https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock] when it's unresponsive.

That should be enough info for a developer to look further into it.

                  
> Segfault in CHAN_SIP - in _int_malloc while in __ast_cc_config_params_init
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-21806
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21806
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.15.0
>         Environment: CPU: Atom D525, RAM 4GB, Fedora Linux, Kernel 2.6.43.8-1.i686
> 2 Aastra endpoints, 1 Polycom IP-650, 1 96 port SIP to analog gateway
> Asterisk 1.8.15-cert2
>            Reporter: Christopher
>            Assignee: Christopher
>         Attachments: core-dump-maxx-052213.txt, valgrind-052213-1530.txt, valgrind-0523-1545-no-malloc.txt, valgrind-good-052213-1930.txt
>
>
> Segfault occurs whether system is idle or is in-use. it will crash within a day or two even if 0 calls are made on it.  running under safe_asterisk, results in multiple crashes within a few minutes until eventually system ends up in a MUTEX lock. over 3 gigs of RAM available and plenty of disk space at time of first crash. Possibly related to the 96 port gateway producing 96 SIP registrations all at once?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira