Summary: | ASTERISK-25415: A11 SIGSEGV 'Double free or corruption' in backtrace from pj_pool_release | ||||
Reporter: | Nicole McIntosh (atna99) | Labels: | |||
Date Opened: | 2015-09-23 13:21:08 | Date Closed: | 2018-01-02 08:44:25.000-0600 | ||
Priority: | Major | Regression? | No | ||
Status: | Closed/Complete | Components: | Channels/chan_sip/General Resources/res_rtp_asterisk | ||
Versions: | 11.19.0 | Frequency of Occurrence | Occasional | ||
Related Issues: |
| ||||
Environment: | Ubuntu 14.04.2 LTS , asterisk version 11.19 updated to trunk, last commit: b4535b0 | Attachments: | ( 0) 7-2-tor_fullbt_sept15_c.txt ( 1) 7-2-tor_fulldebug_sept15_c.txt.gz | ||
Description: | this "double free or corruption" is showing up in many coredumps.
initial bt: {noformat} (gdb) bt #0 0x00007effe91a9cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007effe91ad0d8 in __GI_abort () at abort.c:89 #2 0x00007effe91e6394 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7effe92f4b28 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007effe91f266e in malloc_printerr (ptr=<optimized out>, str=0x7effe92f4c58 "double free or corruption (out)", action=1) at malloc.c:4996 #4 _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3840 #5 0x00007eff90776a2f in default_block_free () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #6 0x00007eff9077d59e in pj_pool_destroy_int () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #7 0x00007eff9077dd9c in cpool_release_pool () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #8 0x00007eff9077cfb6 in pj_pool_release () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #9 0x00007eff9075b6a2 in destroy_tdata () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #10 0x00007eff9075c40f in pj_stun_session_destroy () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #11 0x00007eff90751a20 in destroy_ice () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #12 0x00007eff90751b45 in pj_ice_sess_destroy () from /usr/lib/asterisk/modules/res_rtp_asterisk.so #13 0x00007eff90743bd2 in ast_rtp_destroy (instance=0x7efebc275f28) at res_rtp_asterisk.c:2595 #14 0x0000000000550976 in instance_destructor (obj=0x7efebc275f28) at rtp_engine.c:212 #15 0x000000000044d345 in internal_ao2_ref (user_data=0x7efebc275f28, delta=-1, file=0x5bd3bb "astobj2.c", line=551, func=0x5bd671 <__FUNCTION__.8503> "__ao2_ref") at astobj2.c:469 #16 0x000000000044d64d in __ao2_ref (user_data=0x7efebc275f28, delta=-1) at astobj2.c:551 #17 0x0000000000550ad4 in ast_rtp_instance_destroy (instance=0x7efebc275f28) at rtp_engine.c:231 #18 0x00007eff8a4e77aa in __sip_destroy (p=0x7efed3e9ec48, lockowner=1, lockdialoglist=1) at chan_sip.c:6406 #19 0x00007eff8a4e8c5f in sip_destroy (p=0x7efed3e9ec48) at chan_sip.c:6686 #20 0x00007eff8a4e8bc3 in sip_destroy_fn (p=0x7efed3e9ec48) at chan_sip.c:6675 #21 0x000000000044d345 in internal_ao2_ref (user_data=0x7efed3e9ec48, delta=-1, file=0x5bd3bb "astobj2.c", line=551, func=0x5bd671 <__FUNCTION__.8503> "__ao2_ref") at astobj2.c:469 #22 0x000000000044d64d in __ao2_ref (user_data=0x7efed3e9ec48, delta=-1) at astobj2.c:551 #23 0x00007eff8a4d5e20 in dialog_unref_debug (p=0x7efed3e9ec48, tag=0x7eff8a586e90 "Let's unbump the count in the unlink so the poor pvt can disappear if it is time", file=0x7eff8a585eeb "chan_sip.c", line=3317, func=0x7eff8a59f310 <__PRETTY_FUNCTION__.30399> "dialog_unlink_all") at chan_sip.c:2336 #24 0x00007eff8a4d8f7c in dialog_unlink_all (dialog=0x7efed3e9ec48) at chan_sip.c:3317 #25 0x00007eff8a52a866 in dialog_needdestroy (dialogobj=0x7efed3e9ec48, arg=0x0, flags=6) at chan_sip.c:19667 #26 0x000000000044e677 in internal_ao2_callback (c=0x1048a98, flags=(OBJ_NODATA | OBJ_MULTIPLE), cb_fn=0x7eff8a52a5a6 <dialog_needdestroy>, arg=0x0, data=0x0, type=DEFAULT, tag=0x0, file=0x0, line=0, func=0x0) at astobj2.c:1109 #27 0x000000000044eba2 in __ao2_callback (c=0x1048a98, flags=(OBJ_NODATA | OBJ_MULTIPLE), cb_fn=0x7eff8a52a5a6 <dialog_needdestroy>, arg=0x0) at astobj2.c:1214 #28 0x00007eff8a557dd1 in do_monitor (data=0x0) at chan_sip.c:29340 #29 0x000000000059a430 in dummy_start (data=0x111d550) at utils.c:1223 #30 0x00007effe8100182 in start_thread (arg=0x7effa40c4700) at pthread_create.c:312 #31 0x00007effe926d47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 {noformat} | ||||
Comments: | By: Asterisk Team (asteriskteam) 2015-09-23 13:21:10.416-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: Stefan Engström (StefanEng86) 2015-11-01 10:16:04.653-0600 Any progress with this issue? By: Joshua C. Colp (jcolp) 2017-12-18 06:00:59.773-0600 Is this still a problem under 13 with the latest PJSIP bundled? We use ICE/STUN/TURN more heavily than we did before and have not seen this issue come up. By: Asterisk Team (asteriskteam) 2018-01-02 08:44:25.637-0600 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 |