[asterisk-bugs] [JIRA] (ASTERISK-26620) Segmentation fault in __ast_string_field_alloc_space called from res_digium_phone.so
Namezero (JIRA)
noreply at issues.asterisk.org
Fri Dec 2 13:01:10 CST 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234020#comment-234020 ]
Namezero commented on ASTERISK-26620:
-------------------------------------
Scott, that's great to hear.
Can you provide me a secure way to upload a full dump that is not publicly accessible? I have 3 dumps so far where is issue occurred.
I could also gdb the core with an unstripped red_diigum_phone.so.
The reason I suspect the DPMA module as the offender is that the crash happens now every few days after upgrading from the 1.4 module to the 3.2 module.
Of course the corruption could have happened elsewhere unknowingly before, but the asterisk process ran stable for over 3 years with no issues occurring whatsoever
> Segmentation fault in __ast_string_field_alloc_space called from res_digium_phone.so
> ------------------------------------------------------------------------------------
>
> Key: ASTERISK-26620
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26620
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Affects Versions: 11.2.1
> Environment: CentOS 5 / FreePBX
> Reporter: Namezero
> Assignee: Unassigned
>
> When issuing a "module reload res_digium_phone.so", asterisk segfaults in __ast_string_field_alloc_space. This happens sporadically; and not on every reload.
> DPMA version is 3.2. This issue did not occur with version 1.4.
> The core dump backtrace always looks as follows:
> {noformat}
> #0 __ast_string_field_alloc_space (mgr=0x355cbb0, pool_head=0x355cae8, needed=4) at utils.c:1748
> #1 0x00007ff2c0c68eeb in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
> #2 0x00007ff2c0c784b9 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
> #3 0x00007ff2c0c78a9a in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
> #4 0x00007ff2c0c79d49 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
> #5 0x00007ff2c0c5d9f0 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
> #6 0x00000000004eec98 in ast_module_reload (name=0x7ff20c011eee "res_digium_phone.so") at loader.c:771
> #7 0x0000000000492b69 in handle_reload (e=<value optimized out>, cmd=<value optimized out>, a=0x7ff2b5015d90) at cli.c:296
> #8 0x000000000049592e in ast_cli_command_full (uid=-1, gid=-1, fd=68, s=0x7ff20c0053b9 "module reload res_digium_phone.so") at cli.c:2560
> #9 0x0000000000506ac0 in action_command (s=0x7ff2b5016ba0, m=0x7ff2b50162e0) at manager.c:3893
> #10 0x0000000000509dfe in process_message (s=0x7ff2b5016ba0, m=0x7ff2b50162e0) at manager.c:5123
> #11 0x000000000050cc1c in do_message (data=0x7ff2f0000f08) at manager.c:5336
> #12 session_do (data=0x7ff2f0000f08) at manager.c:5451
> #13 0x0000000000566296 in handle_tcptls_connection (data=0x7ff2f0000f08) at tcptls.c:272
> #14 0x0000000000573468 in dummy_start (data=<value optimized out>) at utils.c:1028
> #15 0x00007ff30ea18851 in start_thread () from /lib64/libpthread.so.0
> #16 0x00007ff30ff8a11d in clone () from /lib64/libc.so.6
> {noformat}
> We are currently investigating the possibility of a 1 second pause between writing the configuration file for DPMA and reloading the module.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list