[asterisk-bugs] [JIRA] (ASTERISK-24590) Segmentation fault in get_multiple_fields_as_var_list
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Wed Dec 3 12:39:29 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-24590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223848#comment-223848 ]
Matt Jordan commented on ASTERISK-24590:
----------------------------------------
Looking at your backtrace, the channel appears to already be destroyed or otherwise in a rather bad state.
Can you provide the ARI calls you're using that reproduce this scenario?
> Segmentation fault in get_multiple_fields_as_var_list
> ------------------------------------------------------
>
> Key: ASTERISK-24590
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24590
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Bridging, Resources/res_stasis
> Affects Versions: 12.7.1
> Environment: uname -a
> Linux astratel 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Anton Evzhakov
> Assignee: Anton Evzhakov
> Severity: Critical
> Attachments: backtrace.txt, backtrace.txt
>
>
> Sometimes asterisk crashes with SIGSEGV while closing bridge connected to stasis.
> {code:title=backtrace.txt|borderStyle=solid}
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00000000005babc1 in get_multiple_fields_as_var_list (object=0x0, object_field=0x1) at sorcery.c:1123
> 1123 if (object_field->multiple_handler(object, &tmp)) {
> #0 0x00000000005babc1 in get_multiple_fields_as_var_list (object=0x0, object_field=0x1) at sorcery.c:1123
> tmp = 0x0
> #1 0x00000000005bac27 in ast_sorcery_objectset_create2 (sorcery=0x7f8a0001dd68, object=0x7f8a00005858, flags=AST_HANDLER_PREFER_STRING) at sorcery.c:1133
> details = 0x0
> object_type = 0x991
> i = {c = 0x7f89e8767dd0, last_node = 0x4828c0 <bridge_channel_wait+108>, complete = 134349144, flags = 32653}
> object_field = 0x7f8a4003fcd8
> head = 0x7f8c340382b8
> tail = 0x7f89e8767d70
> #2 0x00000000005c5f38 in cache_udpate (cached_entry=0x5bac27 <ast_sorcery_objectset_create2+28>, eid=0x7f89e8767d00, new_snapshot=0x0) at stasis_cache.c:451
> new_max = 140230682336616
> new_elems = 0x991
> res = -394887856
> old_snapshot = 0x5c5f38 <cache_udpate+440>
> is_remote = 32649
> idx = 0
> __PRETTY_FUNCTION__ = "cache_udpate"
> #3 0x00000000004c9acb in ast_channel_state_set (chan=0x7f8a4003fcd8, value=AST_STATE_DOWN) at channel_internal_api.c:952
> No locals.
> #4 0x00000000004828c0 in bridge_channel_wait (bridge_channel=0x7f89e8768700) at bridge_channel.c:2282
> __p = 0
> __x = 0
> ms = 0
> outfd = 0
> chan = 0x0
> __PRETTY_FUNCTION__ = "bridge_channel_wait"
> #5 0x000000000046aa04 in bridge_reconfigured (bridge=0x7f8d08020158, colp_update=32649) at bridge.c:1485
> No locals.
> #6 0x00000000005e7705 in udptl_rx_packet (s=0x7f8a4003fcd8, buf=0x0, len=0) at udptl.c:504
> j = 0
> l = 32649
> x = 32
> stat1 = 0
> stat2 = 0
> i = 32653
> ptr = 4729024
> seq_no = 0
> ifp = 0x0
> data = 0x0
> ifp_len = 0
> repaired = {534, -1, 134573088, 32653, 0, 0, 4514738, 0, -394885376, 32649, 0, 0, 4630977, 0, 134349144, 32653}
> bufs = {0x7f8d080174b0 "bridge_channel_depart_thread started at [ 1713] bridge.c ast_bridge_impart()", 0x51954a <format_cap_init+120> "\340H\211P\b\353\fH\213E\330H\307@\b", 0x7f89e8768700 "", 0x9f608fe682867fd9 <error: Cannot access memory at address 0x9f608fe682867fd9>, 0x0, 0x0, 0x7f89e87689c0 "\300I\333\350\211\177", 0x7f89e8768700 "", 0x9f608fe683067fd9 <error: Cannot access memory at address 0x9f608fe683067fd9>, 0x60735fb6924e7fd9 <error: Cannot access memory at address 0x60735fb6924e7fd9>, 0x7f8d00000000 " ", 0x7f89e8767ef0 "", 0x0, 0x7f8d175f2ba2 <error: Cannot access memory at address 0x7f8d175f2ba2>, 0x0}
> lengths = {3900079616, 32649, 4631044, 0, 3900079824, 32649, 134349144, 32653, 0, 0, 134349144, 32653, 3900079824, 32649, 6190853}
> span = 564
> entries = -394885376
> ifp_no = 1073751266
> __PRETTY_FUNCTION__ = "udptl_rx_packet"
> #7 0x00007f8d15dd1182 in ?? ()
> No symbol table info available.
> #8 0x0000000000000000 in ?? ()
> No symbol table info available.
> {code}
> {quote}
> Thread 1 (LWP 7785):
> #0 0x00000000005babc1 in get_multiple_fields_as_var_list (object=0x0, object_field=0x1) at sorcery.c:1123
> #1 0x00000000005bac27 in ast_sorcery_objectset_create2 (sorcery=0x7f8a0001dd68, object=0x7f8a00005858, flags=AST_HANDLER_PREFER_STRING) at sorcery.c:1133
> #2 0x00000000005c5f38 in cache_udpate (cached_entry=0x5bac27 <ast_sorcery_objectset_create2+28>, eid=0x7f89e8767d00, new_snapshot=0x0) at stasis_cache.c:451
> #3 0x00000000004c9acb in ast_channel_state_set (chan=0x7f8a4003fcd8, value=AST_STATE_DOWN) at channel_internal_api.c:952
> #4 0x00000000004828c0 in bridge_channel_wait (bridge_channel=0x7f89e8768700) at bridge_channel.c:2282
> #5 0x000000000046aa04 in bridge_reconfigured (bridge=0x7f8d08020158, colp_update=32649) at bridge.c:1485
> #6 0x00000000005e7705 in udptl_rx_packet (s=0x7f8a4003fcd8, buf=0x0, len=0) at udptl.c:504
> #7 0x00007f8d15dd1182 in ?? ()
> #8 0x0000000000000000 in ?? ()
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list