[Home]

Summary:ASTERISK-22902: Crash when setting RTCP property on RTP instance
Reporter:Private Name (falves11)Labels:
Date Opened:2013-11-25 09:42:56.000-0600Date Closed:2014-01-06 20:43:30.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General Core/RTP
Versions:11.6.0 Frequency of
Occurrence
Related
Issues:
Environment:Linux Debian 7.0Attachments:( 0) backtrace.txt
( 1) frame0.txt
Description:Asterisk crashed and I got a full trace. I am uploading it shortly

\[edit: mjordan\]

The crash occurs during setting up an early bridge between two SIP channels. It appears to be occurring when the RTCP property is being set on a SIP pvt's RTP instance.
Comments:By: Private Name (falves11) 2013-11-25 09:43:30.533-0600

Full trace
By: Matt Jordan (mjordan) 2013-11-25 10:42:48.128-0600

The place where this is crashing is pretty odd:

{noformat}
if (instance->engine->prop_set) {
{noformat}

I can only see this crashing if the {{instance}} pointer is garbage; or if {{engine}} is NULL or garbage.

In both cases, this is highly strange.

If you still have the {{core}} file, please do the following:

# Open it up in {{gdb}}. You should be able to do this using something like: {{gdb -se asterisk -c \[core file name\]}}
# GDB should show that it loads the symbols. Go to frame 0: {{frame 0}}
# Print the value of instance: {{print *instance}}
# If that prints out something valid, also print out the value of engine: {{print instance->engine}}

By: Private Name (falves11) 2013-11-25 10:53:40.168-0600

uploading the file with the info
By: Private Name (falves11) 2013-11-25 11:49:49.048-0600

As requested, frame 0
By: Private Name (falves11) 2013-11-25 11:51:34.027-0600

Full frame 0
By: Matt Jordan (mjordan) 2013-11-25 13:05:59.281-0600

So, somehow engine is NULL. That's pretty weird.
By: Matt Jordan (mjordan) 2013-11-25 13:24:44.684-0600

So I'm not sure how this is possible without having a modified version of Asterisk.

The RTP instance get's its engine pointer set in {{ast_rtp_instance_new}}. *At no point is this pointer ever set to anything else*.

First, the routine obtains the engine name that was requested. If it doesn't find one, the routine bails - in which case there is no RTP instance returned.

{noformat}
/* If an engine name was specified try to use it or otherwise use the first one registered */
if (!ast_strlen_zero(engine_name)) {
AST_RWLIST_TRAVERSE(&engines, engine, entry) {
if (!strcmp(engine->name, engine_name)) {
break;
}
}
} else {
engine = AST_RWLIST_FIRST(&engines);
}

/* If no engine was actually found bail out now */
if (!engine) {
ast_log(LOG_ERROR, "No RTP engine was found. Do you have one loaded?\n");
AST_RWLIST_UNLOCK(&engines);
return NULL;
}
{noformat}

At this point, {{engine}} has to be valid and non-NULL. We assign it to the newly created {{instance}} object below:

{noformat}

/* Bump up the reference count before we return so the module can not be unloaded */
ast_module_ref(engine->mod);

AST_RWLIST_UNLOCK(&engines);

/* Allocate a new RTP instance */
if (!(instance = ao2_alloc(sizeof(*instance), instance_destructor))) {
ast_module_unref(engine->mod);
return NULL;
}
instance->engine = engine;
{noformat}

I don't see how this pointer got set to NULL. We don't assign NULL to {{instance->engine}} at any point in time. Even when the RTP instance of a SIP pvt is destroyed, we still never set that pointer to NULL.

Have you modified your instance of Asterisk?
By: Private Name (falves11) 2013-11-25 13:32:00.948-0600

Absolutely not. I have no idea how to do that.
I can upload the whole asterisk source directory to you and you can see.
No changes.
By: Private Name (falves11) 2013-11-26 09:42:21.673-0600

Question:
Should I upgrade to the latest SVN or you want me to extract some other information from my core dump? I can upload the dump itself and the executable, if needed. So far I left it as is, to help with the investigation.
By: Rusty Newton (rnewton) 2013-12-11 18:32:16.868-0600

@Private Name,

Can you describe reproduction steps and provide a pcap with Asterisk logs (logger.conf, DEBUG and VERBOSE message types) to demonstrate how we can reproduce the crash in-house?

We need very detailed steps so we can reproduce it exactly as you do.
By: Private Name (falves11) 2013-12-14 04:58:11.613-0600

I already upgraded my asterisk and moved on. I cannot reproduce it.
However, I am running non-optimized and if it happens again I will get another trace.
That is what I can do, since I cannot run with permanently with debug and verbose.
I think that if GDB cannot tell what is wrong, than we have systemic problem.
Please think about this. The dump should indicate fully the state of the software.
By: Rusty Newton (rnewton) 2014-01-06 20:43:30.677-0600

Closing this out, as we cannot reproduce. Feel free to ask us to re-open when you get an additional trace, despite not being able to get the un-optimized trace. It may not be useful, but we'll take a look. Ask a bug marshal to re-open in #asterisk-bugs when you get more information.