Summary:ASTERISK-12490: When I try to load asterisk it crashes
Reporter:Private Name (falves11)Labels:
Date Opened:2008-07-30 20:26:26Date Closed:2008-08-02 10:46:10
Versions:Frequency of
Environment:Attachments:( 0) blowup.txt
( 1) blowup1.txt
( 2) blowup2.txt
( 3) blowup3_version_trunk134705.txt
Description:Please see the attached files
Comments:By: Private Name (falves11) 2008-07-30 20:28:47

The only unusual thing now is that I am compiling Asterisk with malloc debug.

In my asterisk.conf I have

By: Private Name (falves11) 2008-07-30 20:55:02

I can make the current version of trunk crash when it loads. Please take a look at the latest upload.

By: Steve Murphy (murf) 2008-07-31 18:47:54

Hmmm. It didn't have any problems when I checked in the last changes. Before I dive into this, I need to know what you have for extensions.conf and extensions.ael.

Does it only crash with MALLOC_DEBUG turned on? It doesn't crash otherwise?

By: Private Name (falves11) 2008-08-01 05:16:10

You hit right in the nail. It crashes only when compiled with malloc debug. Do you stil need to see my dialplan?
The box is not in production, so I can give you access to it if you want to take a look. Please contact me falves1@hotmai.com

By: Steve Murphy (murf) 2008-08-01 13:23:30

OK, I can repro here. It's pretty simple; whatever astmm is doing, it's pretty swiftly fatal. Won't load very far before you explode.

By: Private Name (falves11) 2008-08-01 19:43:57

please let me know when it is fixed. I need to compile it with malloc debug, for sometimes it gets to 1.5 GB of ram without any calls open.

By: Digium Subversion (svnbot) 2008-08-01 23:43:08

Repository: asterisk
Revision: 135265

U   trunk/main/features.c
U   trunk/main/pbx.c

r135265 | murf | 2008-08-01 23:43:07 -0500 (Fri, 01 Aug 2008) | 31 lines

(closes issue ASTERISK-12490)
Reported by: falves11
Tested by: murf

falves11 ==

The changes I introduce here seem to clear up the problem
for me. However, if they do not for you, please reopen this
bug, and we'll keep digging.

The root of this problem seems to be a subtle memory corruption
introduced when creating an extension with an empty extension
name. While valgrind cannot detect it outside of DEBUG_MALLOC
mode, when compiled with DEBUG_MALLOC, this is certain death.

The code in main/features.c is a puzzle to me. On the initial
module load, the code is attempting to add the parking extension
before the features.conf file has even been opened!

I just wrapped the offending call with an if() that will not
try to add the extension if the extension name is empty. THis
seems to solve the corruption, and let the "memory show allocations"
work as one would expect.

But, really, adding an extension with an empty name is a seriously
bad thing to allow, as it will mess up all the pattern matching
algorithms, etc. So, I added a statement to the add_extension2 code to return
a -1 if this is attempted.