[Home]

Summary:ASTERISK-23348: Allocation failure in ast_unreal_new_channels causes core dump
Reporter:Corey Farrell (coreyfarrell)Labels:
Date Opened:2014-02-22 00:51:53.000-0600Date Closed:2014-05-30 13:12:15
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/Channels
Versions:SVN 12.0.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace_2414.txt
( 1) testsuite-error.txt
Description:Testsuite crashed on tests/masquerade.  Backtrace and testsuite error messages attached.
Comments:By: Matt Jordan (mjordan) 2014-02-23 21:45:04.410-0600

It shouldn't crash, but I suspect you ran into this when running the test without enough file descriptors. If you bump the limit, does the test run into the same allocation error?
By: Corey Farrell (coreyfarrell) 2014-02-24 00:31:23.694-0600

You are right, {{ast_channel_internal_alertpipe_init}} failed.  I found this by adding abort() to the error conditions of {{__ast_channel_alloc_ap}}.  Also, ulimit -n is 1024.

As for the limit, I'm not sure how many channels are being created but the backtrace only shows 225 threads.  I would guess this is due to my using timerfd, and the fix for ASTERISK-16783 (extra fd's from ast_channel_internal_alertpipe_init).
By: Matt Jordan (mjordan) 2014-05-30 09:31:34.838-0500

Pretty sure I just fixed this, without realizing this was the same issue:

{code}
------------------------------------------------------------------------
r414542 | mjordan | 2014-05-24 21:30:51 -0500 (Sat, 24 May 2014) | 15 lines

core_unreal: Prevent double free of core_unreal pvt

When a channel is destroyed (such as via ast_channel_release in off nominal
paths in core_unreal), it will attempt to free (via ast_free) the channel tech
pvt. This is problematic for a few reasons:
1. The channel tech pvt is an ao2 object in core_unreal. Free'ing the pvt
  directly is no good.
2. The channel tech pvt's reference count is dropped just prior to calling
  ast_channel_release, resulting in the pvt's destruction. Hence, the
  channel destructor is free'ing an invalid pointer.

This patch keeps the dropping of the reference count, but sets the pvt to
NULL on the channel prior to releasing it. This models what would occur if the
channel was hung up directly.
{code}

I ran into this doing something similarly aggressive with Local channels. One of the channels doesn't get created for some reason, and - because the pvt gets destroyed before the channel - the {{ast_channel_destructor}} free's an already free'd location.

Unless you feel otherwise, I'm going to propose we close out this issue as "Fixed" - if it turns out I'm wrong, we can re-open the issue.