[ https://issues.asterisk.org/jira/browse/ASTERISK-26620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233987#comment-233987 ]
Namezero commented on ASTERISK-26620:
-------------------------------------
I can provide more debug information if required.
However, I believe the problem is in the DPMA module. We reload the module up to 100 times daily; often in short intervals, as every user login on a phone results in a reconfig.
The last crash happened from the DPMA module in malloc_consolidate(); a telltale signe for me that DPMA trashed memory:
===========================================================================
#0 0x00007fe78086ca53 in malloc_consolidate () from /lib64/libc.so.6
#1 0x00007fe78086f3d8 in _int_free () from /lib64/libc.so.6
#2 0x00007fe73171a0c3 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
#3 0x00007fe73171a779 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
#4 0x00007fe73171e12f in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
#5 0x00007fe73171ed49 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
#6 0x00007fe7317029f0 in ?? () from /usr/lib64/asterisk/modules/res_digium_phone.so
#7 0x00000000004eec98 in ast_module_reload (name=0x7fe68805ab7e "res_digium_phone.so") at loader.c:771
#8 0x0000000000492b69 in handle_reload (e=<value optimized out>, cmd=<value optimized out>, a=0x7fe725659d90) at cli.c:296
#9 0x000000000049592e in ast_cli_command_full (uid=-1, gid=-1, fd=74, s=0x7fe6881675f9 "module reload res_digium_phone.so") at cli.c:2560
#10 0x0000000000506ac0 in action_command (s=0x7fe72565aba0, m=0x7fe72565a2e0) at manager.c:3893
#11 0x0000000000509dfe in process_message (s=0x7fe72565aba0, m=0x7fe72565a2e0) at manager.c:5123
#12 0x000000000050cc1c in do_message (data=0x7fe760000cf8) at manager.c:5336
#13 session_do (data=0x7fe760000cf8) at manager.c:5451
#14 0x0000000000566296 in handle_tcptls_connection (data=0x7fe760000cf8) at tcptls.c:272
#15 0x0000000000573468 in dummy_start (data=<value optimized out>) at utils.c:1028
#16 0x00007fe77f36c851 in start_thread () from /lib64/libpthread.so.0
#17 0x00007fe7808df11d in clone () from /lib64/libc.so.6
===========================================================================
Do you have contact to someone at Digium? They refuse to look at DPMA issues when issued merely a bug report.
Thanks for the tip with the version switch. Our FreePBX version has some customizations; e.g. locale-dependent announcements, extra hints, etc. This version only supports switching to older Asterisk versions. I will discuss the repercussions of a full upgrade with the team; I will advise then.
> 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)