[asterisk-bugs] [JIRA] (ASTERISK-26620) Segmentation fault in __ast_string_field_alloc_space called from res_digium_phone.so
Scott Griepentrog (JIRA)
noreply at issues.asterisk.org
Fri Dec 2 09:01:10 CST 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233997#comment-233997 ]
Scott Griepentrog commented on ASTERISK-26620:
----------------------------------------------
> contact to someone at Digium
I work for Digium, and am the maintainer of the DPMA project. Diagnosing DPMA issues is often very difficult. Usually a simple bug report is not enough to go on. A full copy of the backtrace output - not just one thread - is most useful as the state of other threads sometimes provides necessary context to understand the problem, or at least what isn't part of the problem. Please follow these instructions to obtain a full trace file (skipping the part about recompiling Asterisk in your case): https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace
I agree that memory corruption is most likely at fault in this crash. The problem with memory corruption is that it's global - the fault can be in one component, and not be exposed until a change in another component triggers it, and then start "appearing" as crashes in random parts of the code.
I have opened up an internal issue (separate private Jira instance) to review locking around the string field usage in DPMA. It's the most likely scenario, but ultimately may not be the answer. At this point it's my best guess with a small amount of data. There are several additional diagnostic steps that can be taken, should that path not pan out. I appreciate your patience and willingness to cooperate in providing data and testing new versions as I work to resolve this issue.
> 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