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-0600 | Date Closed: | 2014-01-06 20:43:30.000-0600 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/General Core/RTP |
Versions: | 11.6.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Linux Debian 7.0 | Attachments: | ( 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. |