[Home]

Summary:ASTERISK-00610: Increasing AST_MAX_EXTENSION makes app_dial segfault
Reporter:thansen (thansen)Labels:
Date Opened:2003-12-02 08:50:43.000-0600Date Closed:2004-09-25 02:49:15
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I.e. set AST_MAX_EXTENSION in channel.h to 512, compile-install-run and call dial() from the dialplan.

****** ADDITIONAL INFORMATION ******

backtrace:

#0  0x40598be8 in dial_exec (chan=0x0, data=0xbeffe3dc) at app_dial.c:510
510                     tmp->chan = ast_request(tech, chan->nativeformats, numsubst);
Comments:By: Brian West (bkw918) 2003-12-02 10:03:02.000-0600

Why on earth would you need it to be set to 512?
By: Brian West (bkw918) 2003-12-02 10:08:07.000-0600

Also attach a full bt
By: thansen (thansen) 2003-12-02 10:41:33.000-0600

As in "bt full". The last call (#0) was all I could get with bt. (new thread, perhaps?)

I knew someone would ask why I would need to increase extension size. :)

Imagine an extension like this:

exten => s,1,MySQLquery(foo=db|"SELECT foo FROM bar LIMIT 1")

Select statements can grow quite large when joining tables etc. I hit this problem with a statement of 465 bytes, so I chose to try and increase the extension size to 512 to leave some room.

Also, even though AST_MAX_EXTENSION is set to 80, at least 214 bytes are somehow still stored. Couldn't figure out why this is possible. I fear there might be a buffer overflow somewhere.
By: jerjer (jerjer) 2003-12-02 11:03:01.000-0600

Why in hell would you even contemplate such a application?

A
G
I Use it.
By: Brian West (bkw918) 2003-12-02 11:06:12.000-0600

The select statement wouldn't have anything to do with the AST_MAX_EXTENSION, the responsibility of that would be app_db_mysql and not anything to do with extension size.  The return value on the otherhand might but then again why can't it stay within the limits of what * has been setup for?

What are you trying to dial?  Around the world and back?

Give me an example of what an SQL query might return and what it might look like when you dial.
By: Mark Spencer (markster) 2003-12-02 16:26:52.000-0600

Did you do "make clean ; make install"?
By: thansen (thansen) 2003-12-03 06:52:17.000-0600

JerJer: *sigh* Because it makes Asterisk extremely dynamic to us while staying "selfcontained".

bkw918: It has nothing to do with the returned data of the app. The result of the query is not in any way used by the dial command (not in this case anyway) Heck, even removing the mysqlquery app completely and just calling dial() when AST_MAX_EXTENSION is increased, it will segfault.

Using debug output I can see that more and more of the exten line gets loaded when increasing AST_MAX_EXTENSION. But when set to the default 80, 256 bytes still gets loaded. So there's a hardcoded limit somewhere, which probably should have been set to AST_MAX_EXTENSION instead. This limit might also be what's causing dial() to die.

markster: Yes, several times. Setting it back to 80, it runs fine again.
By: Mark Spencer (markster) 2003-12-03 08:56:18.000-0600

ast_max_extension only affects the extension side, not the data side.

there was an improper strncpy that your experiment found (and is now fixed).
By: Brian West (bkw918) 2003-12-04 11:55:31.000-0600

Can you please reply and let me know if this is still an issue or not?
By: thansen (thansen) 2003-12-05 04:08:38.000-0600

Yes, dial no longer crashes. Thanks.

The ast_exten struct in pbx.c declares char app[AST_MAX_EXTENSION] which effectively limits the size of the application name. I thought this was including the app parameters, which I can see now isn't correct. I was barking up the wrong tree.

Seems like its the size of buf in config.c that's the actual limit here. Need to test it first though.

Thanks.
By: Brian West (bkw918) 2003-12-06 11:07:17.000-0600

Fixed in CVS