[Home]

Summary:ASTERISK-24726: Cleaned ast_channel in file.c waitstream_core
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2015-01-27 06:42:13.000-0600Date Closed:2015-03-31 04:26:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General Resources/res_agi
Versions:13.1.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description: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.
Comments:By: Walter Doekes (wdoekes) 2015-02-12 06:27:13.647-0600

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.
By: Walter Doekes (wdoekes) 2015-03-31 04:26:27.580-0500

Upgraded all to asterisk 13.2.

Customer only had these issues on one of his machines. (Might be hardware problems?)

No other info is available. Closing out.