Summary:	ASTERISK-05407: Overflow at calculations causes 100% CPU usage
Reporter:	Jon Brüel (jb)	Labels:
Date Opened:	2005-10-31 15:07:08.000-0600	Date Closed:	2011-06-07 14:10:08
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) Dialplan.txt
Description:	CPU usage goes to 100% after compare operations with large numbers. ****** ADDITIONAL INFORMATION ****** When compare calculations is done in GotoIf, where one of the operands is larger than 2^63, the CPU usage goes to 100%. Existing calls stay connected but no new calls are processed. I believe this is a general problem in mathematical calculations due to lack of boundary check of the operands prior to the calculation. It can be avoided by limiting the numbers to e.g. 19 digits, but it would be nicer if the code was foolproof. (General documentation of this any boundary limits would be nice too.) No dump is attached as I suspect the error may be easily solved by tidying up the code.
Comments:	By: Mark Spencer (markster) 2005-10-31 18:55:39.000-0600 Can you provide a sample entry? By: Jon Brüel (jb) 2005-11-01 03:46:24.000-0600 A file with the macro-exttypeA is attached. A note in the file shows where it goes wrong when the operand is too large. Just after this happens the message log gives the message overflow and the CPU goes to 100% load. By: BJ Weschke (bweschke) 2005-11-01 08:27:07.000-0600 Is there sample data or a debug trace that demonstrates what happens when this breaks? I'd like to test it with CVS-HEAD as well since you indicate this is happening now on the v1.0 tree. By: Kevin P. Fleming (kpfleming) 2005-11-01 17:21:38.000-0600 The expression parser in CVS HEAD is nearly completely different from the one 1.0.x, so I suspect this problem will not occur there. By: Jon Brüel (jb) 2005-11-02 04:01:10.000-0600 I have now updated to the last HEAD (using "asterisk-update update dev" -although the show version doesn't say HEAD), and this time the system crashes a few execution lines after the overflow. Below the few relevant lines from the CLI are shown vith verbose set to 255. If required I may also supply you with a core dump. blade1*CLI> show version Asterisk CVS-v1-0-11/02/05-10:12:43 built by root@blade1 on a i686 running Linux blade1*CLI> Nov  2 10:40:41 WARNING[24600]: ast_expr.y:244 to_integer: overflow    -- Executing GotoIf("SIP/36926783-3e81", "0?4000:404") in new stack    -- Goto (macro-exttypeA,s,404)    -- Executing GotoIf("SIP/36926783-3e81", "0?4000:600") in new stack    -- Goto (macro-exttypeA,s,600)    -- Executing SetVar("SIP/36926783-3e81", "number1=SIP/100000020780") in new stack    -- Executing SetVar("SIP/36926783-3e81", "CFIM=0") in new stack    -- Executing ODBCget("SIP/36926783-3e81", "CFIM=K00000020/MYPHONE780CFIM") in new stack    -- odbcget: varname=CFIM, family=K00000020, key=MYPHONE780CFIM blade1*CLI> Disconnected from Asterisk server Executing last minute cleanups Asterisk cleanly ending (0). [root@blade1 asterisk]# By: BJ Weschke (bweschke) 2005-11-02 08:29:40.000-0600 jb: your show version still indicates that what you're running is not CVS-HEAD. It may be an updated version of the 1.0 tree, but it's not CVS-HEAD. You can download the b2 src tarball from http://ftp.digium.com/pub/asterisk/asterisk-1.2.0-beta2.tar.gz or you can use CVS and do "cvs checkout asterisk" leaving out the "-r v1-0". By: Jon Brüel (jb) 2005-11-03 07:38:48.000-0600 I have tried to use Asterisk 1.2 beta, but I have problems with app_dbodbc, which compiles OK (using the version on http://www.asterisk-support.de/mirror/odbc/cvs-head-stuff/ from 24-May-2005, copying func.rtdb and app_dbodbc.c to the two directories, and changing the makefile in the app directory). Starting Asterisk I get the error: Loading module app_dbodbc.so failed. The dialplan heavily uses this application, so I really need it for proper testing, and it would be nice if it was a part of the standard package. By: BJ Weschke (bweschke) 2005-11-03 07:45:17.000-0600 It is not part of the standard package I think because of licensing issues. If you cannot get 1.2b2 running on your system so that we can test, can I ask that we close this bug out for now and, once you do get 1.2b2 running, if you still are having the issue, you should absolutely re-open this bug. By: Jon Brüel (jb) 2005-11-03 15:34:15.000-0600 I have now checked with version 1.2 beta2, and the overflow situation is handled nicely, as it ought to. By: BJ Weschke (bweschke) 2005-11-03 15:36:58.000-0600 Issue doesn't exist with 1.2b2. Resolution is to upgrade when using values with that large a range.