[Home]

Summary:ASTERISK-27154: Asterisk crash on stasis publish of channel leaving bridge event
Reporter:BJ Weschke (bweschke)Labels:
Date Opened:2017-07-24 11:30:12Date Closed:2020-01-14 11:13:42.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_ari_device_states Resources/res_stasis_device_state
Versions:13.7.2 Frequency of
Occurrence		One Time
Related
Issues:
Environment:Attachments:( 0) asterisk-bt.2017-07-23.txt
Description:from backtrace
{noformat}
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x0809b16a in INTERNAL_OBJ (user_data=0x15) at astobj2.c:124
124             if (AO2_MAGIC != p->priv_data.magic) {
#0  0x0809b16a in INTERNAL_OBJ (user_data=0x15) at astobj2.c:124
       p = 0x1
       __PRETTY_FUNCTION__ = "INTERNAL_OBJ"
#1  0x0809b833 in internal_ao2_ref (user_data=0x15, delta=1, file=0x824944b "astobj2.c", line=516, func=0x8249694 "__ao2_ref") at astobj2.c:405
       obj = 0xb132dad0
       obj_mutex = 0xb1d3b578
       obj_rwlock = 0xaf6c60e8
       current_value = 2
       ret = 1
       __PRETTY_FUNCTION__ = "internal_ao2_ref"
#2  0x0809bbb4 in __ao2_ref (user_data=0x15, delta=1) at astobj2.c:516
       __FUNCTION__ = "__ao2_ref"
#3  0x081faa4a in publish_msg (topic=0x15, message=0xb1d3b5ac, sync_sub=0x0) at stasis.c:808
       i = 4294967295
       __PRETTY_FUNCTION__ = "publish_msg"
#4  0x081fab30 in stasis_publish (topic=0x15, message=0xb1d3b5ac) at stasis.c:823
No locals.
#5  0x081fd837 in bridge_publish_state_from_blob (bridge=0xafbf2c5c, obj=0xae65091c) at stasis_bridges.c:304
       msg = 0xb1d3b5ac
#6  0x081fde25 in ast_bridge_publish_leave (bridge=0xafbf2c5c, chan=0xa82b15bc) at stasis_bridges.c:477
       msg = 0xae41b9ec
#7  0x080c0ea3 in bridge_channel_internal_pull (bridge_channel=0xa7f6f8cc) at bridge_channel.c:2037
       bridge = 0xafbf2c5c
       __PRETTY_FUNCTION__ = "bridge_channel_internal_pull"
#8  0x080c2745 in bridge_channel_internal_join (bridge_channel=0xa7f6f8cc, cond=0xac047c44) at bridge_channel.c:2692
       res = 0
       channel_features = 0x0
       swap = 0x0
       __PRETTY_FUNCTION__ = "bridge_channel_internal_join"
#9  0x080aa0b6 in bridge_channel_ind_thread (data=0xac047c44) at bridge.c:1620
       cond = 0xac047c44
       bridge_channel = 0xa7f6f8cc
       chan = 0xae4053f0
       __PRETTY_FUNCTION__ = "bridge_channel_ind_thread"
#10 0x08225d87 in dummy_start (data=0xade21938) at utils.c:1237
       __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {-1221865484, 0, 4001536, -1351851224, -1046362814, 1574889996}, __mask_was_saved = 0}}, __pad = {0xaf6c63e4, 0x0, 0xb72bd228, 0x16}}
       __cancel_routine = 0x808f1fd <ast_unregister_thread>
       __cancel_arg = 0xaf6c6b40
       __not_first_call = 0
       ret = 0xb713eff4
       a = {start_routine = 0x80aa077 <bridge_channel_ind_thread>, data = 0xac047c44, name = 0xae4053a0 "bridge_channel_ind_thread started at [ 1713] bridge.c ast_bridge_impart()"}
#11 0xb72abd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
No symbol table info available.
#12 0xb708887e in clone () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2017-07-24 11:30:13.498-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: BJ Weschke (bweschke) 2017-07-24 11:32:42.544-0500

Full backtrace from core dump file
By: Rusty Newton (rnewton) 2017-07-24 18:20:52.350-0500

Are you able to reproduce in a more recent version of 13? The version you are using is getting pretty old at this point and many issues have been fixed since then.

If you can reproduce on a current version it would also be helpful to get a debug log during the crash.

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: BJ Weschke (bweschke) 2017-07-25 09:15:08.947-0500

This happened in our production environment, so I'm going to have to go through a full SDLC to get the version of Asterisk 13 updated. I do have a DEBUG log from the original event on Sunday evening if it's helpful, but it's fairly large in size. I've taken a cursory look at this particular channel that was coming out of the bridge which triggered the crash, and I can't see anything that different in its lifecycle vs. others like it that come through tens of thousands of times per day.
By: Rusty Newton (rnewton) 2017-07-27 08:32:09.375-0500

If you can attach just the last 1000 lines or so of the log as a .txt, that is all we would need. Feel free to sanitize it if necessary.

One of our core developers looked over the backtrace and believes this issue was fixed a while ago. However we were not able to pin it down to a specific commit yet.
By: Asterisk Team (asteriskteam) 2017-08-10 12:00:01.890-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