[asterisk-bugs] [JIRA] (ASTERISK-24726) Cleaned ast_channel in file.c waitstream_core

[Walter Doekes (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224881#comment-224881 ] 

Walter Doekes commented on ASTERISK-24726:
------------------------------------------

Okay. Customer has gotten second crash. Same style -- apparent cleanup during a point there a cleanup is not expected -- different location:

{noformat}
(gdb) up
#3  ast_rtp_remote_address_set (instance=0x7fe258174e78, addr=0x7fe258174f28) at res_rtp_asterisk.c:4733
4733			ast_sockaddr_copy(&rtp->rtcp->them, addr);
(gdb) print rtp->rtcp
$4 = (struct ast_rtcp *) 0x0
(gdb) list
4731		if (rtp->rtcp) {
4732			ast_debug(1, "Setting RTCP address on RTP instance '%p'\n", instance);
4733			ast_sockaddr_copy(&rtp->rtcp->them, addr);
{noformat}

I hope to get more info out of the full logs this time.

> Cleaned ast_channel in file.c waitstream_core
> ---------------------------------------------
>
>                 Key: ASTERISK-24726
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24726
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General, Resources/res_agi
>    Affects Versions: 13.1.0
>            Reporter: Walter Doekes
>
> For asterisk 13.1.0, I have this backtrace:
> {noformat}
> ...
> waitstream_core at file.c:1547
> ast_waitstream_full at file.c:1610
> handle_streamfile at res_agi.c:2228
> agi_handle_command ... buf=... "STREAM" ... at res_agi.c:3671
> run_agi ... request=... "agi://127.0.0.1:17902" ... at res_agi.c:3868
> {noformat}
> .. for a crash that happens in {{ast_sched_runq}} because it is fed a
> NULL pointer which came from chan->sched.
> Barring memory corruption, this means that {{ast_hangup()}} has been
> called -- because it's the only function that sets chan->sched to NULL
> on the channel object while it is in this loop in file.c:
> {noformat}
> static int waitstream_core(struct ast_channel *c,
> ...
>         while (ast_channel_stream(c)) {
> ...
>                 ms = ast_sched_wait(ast_channel_sched(c));
> ...
> ...
>                 ast_sched_runq(ast_channel_sched(c)); // CRASH!
>         }
> {noformat}
> Somewhere in that loop, most attributes of 'c' got unset, resulting
> in a NULL dereference.
> The channel appears to be unlocked here (right?).
> So, who has the power to {{ast_hangup()}} this channel while we're in this loop?
> ----
> Additional info:
> * c is mostly empty (c->chan is NULL, c->generator is NULL), so my best
>   guess is that ast_hangup() was called.
> * Hangupsource is set {{hangupsource = 0x3bb2bb8 "PJSIP/proxy-00002e65"}}.
> * A few chanvars are set:
> {noformat}
> {entries = {next = 0x7f7adca95b60}, value = 0x3b223ca "HANGUP", name = 0x3b223c0 "AGISTATUS"}
> {entries = {next = 0x349f4b0}, value = 0x7f7adca95b7f "FAILED", name = 0x7f7adca95b70 "PLAYBACKSTATUS"}
> {entries = {next = 0x0}, value = 0x349f4cf "inbound", name = 0x349f4c0 "call-direction"}
> {noformat}
> * run_agi was called from pbx_exec by {{AGI("agi://127.0.0.1:17902")}} dialplan code.



--
This message was sent by Atlassian JIRA
(v6.2#6252)