[Home]

Summary:ASTERISK-26192: ARI: channel hangup make asterisk crash (ast_hangup)
Reporter:Javier Riveros (goseeped)Labels:
Date Opened:2016-07-13 11:42:53Date Closed:2020-01-14 11:14:08.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_pjsip Resources/res_ari
Versions:13.9.1 Frequency of
Occurrence		Occasional
Related
Issues:
Environment:Attachments:( 0) asterisk_core_1468350189.zip
Description:The following call :

PSTN -> proxy -> (first call leg ) Asterisk ->(second call leg) proxy -> Webrtc (endpoint)

The call was working just fine for 20 minutes then when the call was hangup on the PSTN site asterisk try to clear the bridge and then just crash.


The coredumps looks like this

{noformat}
#0  0x00007ffa615bec37 in __GI_raise (sig=sig@entry=6)
   at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffa615c2028 in __GI_abort () at abort.c:89
#2  0x00007ffa615fb2a4 in __libc_message (do_abort=do_abort@entry=1,
   fmt=fmt@entry=0x7ffa617096b0 "*** Error in `%s': %s: 0x%s ***\n")
   at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffa616069b2 in malloc_printerr (ptr=<optimized out>,
   str=0x7ffa617057e4 "corrupted double-linked list", action=1)
   at malloc.c:4996
#4  malloc_consolidate (av=av@entry=0x7ffa48000020) at malloc.c:4165
#5  0x00007ffa61607ce8 in _int_malloc (av=av@entry=0x7ffa48000020,
   bytes=bytes@entry=4048) at malloc.c:3423
#6  0x00007ffa6160b1dc in __libc_calloc (n=<optimized out>,
   elem_size=<optimized out>) at malloc.c:3219
#7  0x00000000005fcea0 in _ast_calloc (num=1, len=4048,
   file=0x668390 "stringfields.c", lineno=66,
   func=0x6683bb <__PRETTY_FUNCTION__.8211> "calloc_wrapper")
   at /tmp/tmp.HazODY9iIn/asterisk-13.9.1/include/asterisk/utils.h:573
#8  0x00000000005e4ae6 in calloc_wrapper (num_structs=1, struct_size=4048,
   file=0x666f0b "stasis_channels.c", lineno=214,
   func=0x667630 <__PRETTY_FUNCTION__.15194> "ast_channel_snapshot_create")
   at stringfields.c:66
#9  0x00000000005e4b3b in add_string_pool (mgr=0x7ff9e9930ce0,
   pool_head=0x7ff9e9930c20, size=1024, file=0x666f0b "stasis_channels.c",
   lineno=214,
   func=0x667630 <__PRETTY_FUNCTION__.15194> "ast_channel_snapshot_create")
   at stringfields.c:80
#10 0x00000000005e50f7 in __ast_string_field_init (mgr=0x7ff9e9930ce0,
   pool_head=0x7ff9e9930c20, needed=1024, file=0x666f0b "stasis_channels.c",
   lineno=214,
   func=0x667630 <__PRETTY_FUNCTION__.15194> "ast_channel_snapshot_create")
   at stringfields.c:222
#11 0x00000000005d5099 in ast_channel_snapshot_create (chan=0x7ff9e9b236d8)
   at stasis_channels.c:214
#12 0x00000000004adb5f in create_channel_snapshot_message (
   channel=0x7ff9e9b236d8) at channel.c:668
#13 0x00000000004adc07 in publish_cache_clear (chan=0x7ff9e9b236d8)
   at channel.c:682
#14 0x00000000004b1cc0 in ast_channel_destructor (obj=0x7ff9e9b236d8)
   at channel.c:2201
#15 0x000000000045d6bf in internal_ao2_ref (user_data=0x7ff9e9b236d8,
   delta=-1, file=0x62402b "astobj2.c", line=516,
   func=0x624251 <__FUNCTION__.8645> "__ao2_ref") at astobj2.c:445
#16 0x000000000045d989 in __ao2_ref (user_data=0x7ff9e9b236d8, delta=-1)
   at astobj2.c:516
#17 0x00000000004b341e in ast_hangup (chan=0x7ff9e9b236d8) at channel.c:2692
#18 0x0000000000477a49 in ast_bridge_run_after_goto (chan=0x7ff9e9b236d8)
   at bridge_after.c:545
#19 0x000000000046d80f in bridge_channel_ind_thread (data=0x7ff9e9b1f338)
   at bridge.c:1784
#20 0x00000000005fea8c in dummy_start (data=0x7ff9f2ca5220) at utils.c:1235
#21 0x00007ffa623c2184 in start_thread (arg=0x7ff9fab70700)
   at pthread_create.c:312
#22 0x00007ffa6168237d in clone ()
   at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0  0x00007ffa615bec37 in __GI_raise (sig=sig@entry=6)
   at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
       resultvar = 0
       pid = 15593
       selftid = 19317
#1  0x00007ffa615c2028 in __GI_abort () at abort.c:89
       save_stage = 2
       act = {__sigaction_handler = {sa_handler = 0x3000000028,
           sa_sigaction = 0x3000000028}, sa_mask = {__val = {
             140711629879952, 140711629879760, 140712926511136,
             18446744073709551615, 107, 9007199254740992, 0,
             140711629883136, 6602303, 32, 140707423584363, 206158430248,
             140711629880048, 140711629879856, 0, 140711629877536}},
         sa_flags = 1633695305, sa_restorer = 0x7ff9fab6f700}
       sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007ffa615fb2a4 in __libc_message (do_abort=do_abort@entry=1,
   fmt=fmt@entry=0x7ffa617096b0 "*** Error in `%s': %s: 0x%s ***\n")
   at ../sysdeps/posix/libc_fatal.c:175
       ap = {{gp_offset = 40, fp_offset = 0,
           overflow_arg_area = 0x7ff9fab6f370,
           reg_save_area = 0x7ff9fab6f300}}
{noformat}

Im attaching the full logs that include the sip packets and the pjsip configuration.

The callID of the call that make asterisk crash is {{Hj5jUo8wPqJSiDA7xNUXTEJZAgf}} so you can track the ari events

New information required let me know.

Comments:By: Asterisk Team (asteriskteam) 2016-07-13 11:42:54.229-0500

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: Matt Jordan (mjordan) 2016-07-13 19:51:22.642-0500

Your backtrace appears to contain a memory corruption. We need one or both of the following items to continue investigation of the issue:
1. Valgrind output. See https://wiki.asterisk.org/wiki/display/AST/Valgrind for instructions on how to use Valgrind with Asterisk.
2. MALLOC_DEBUG output. See https://wiki.asterisk.org/wiki/display/AST/MALLOC_DEBUG+Compiler+Flag for instructions on how to use the MALLOC_DEBUG option.

Note that MALLOC_DEBUG and Valgrind are mutually exclusive options. Valgrind output is preferable, but will be more system resource intensive and may be difficult to get on a production system. In such a case, you may have better luck getting the necessary output from MALLOC_DEBUG.


By: Javier Riveros (goseeped) 2016-07-14 12:21:19.383-0500

@Matt Jordan thanks for your response, i will try to reproduce with this flags enable and let you know !
By: Asterisk Team (asteriskteam) 2016-07-29 12:00:01.747-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines