[asterisk-bugs] [Asterisk 0012695]: Incorrect usage of errno can cause segfaults in ast_expr2.y

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12695 
====================================================================== 
Reported By:                ardjan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12695
Category:                   Core/Portability
Reproducibility:            sometimes
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 117400 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-21-2008 04:02 CDT
Last Modified:              05-22-2008 02:42 CDT
====================================================================== 
Summary:                    Incorrect usage of errno can cause segfaults in
ast_expr2.y
Description: 
Several of our live asterisk servers experienced crashes after printing the
following log line:

Conversion of 1 to number under/overflowed!

Further research led us to the file main/ast_expr2.y where this line is
printed on line 578 in the function "to_number". If this error is printed
this function frees vp->u.s and returns 0. This function is used quite
often without checking for errors, so subsequent usage of the passed struct
can (and does) cause segfaults.

Although each unchecked use of to_number could be called a bug this isn't
the real problem here (and in fact it is quite understandable). Looking
into the code of ast_expr2.y and considering the fact that the value 1
clearly doesn't cause an over- or underflow we came to the conclusion that
errno must have been changed by another thread, so in fact it is used in a
thread-unsafe manner.
 
During compilation of asterisk the compiler option -D_REENTRANT is passed,
but looking at errno.h we came to the conclusion that it is also necessary
to pass the compile option -D_LIBC_REENTRANT to make errno thread safe. 

We compiled asterisk with this option and have had no crashes for several
weeks, before this change we had a crash every couple of days.

Our live servers are currently running Asterisk 1.2.24 but I checked the
current asterisk SVN (revision 117400) trunk and the same problem is
possible here. I assume that this problem is present in all versions.

So assuming that this extra compile option indeed fixed this problem I
would advise to add -D_LIBC_REENTRANT on every place where -D_REENTRANT is
set.

Kind regards,
Ardjan Zwartjes.
====================================================================== 

---------------------------------------------------------------------- 
 ardjan - 05-22-08 02:42  
---------------------------------------------------------------------- 
We are using a Linux 2.6.18 system, so if what you're saying is true our
change shouldn't have made a difference, the funny thing is however that
since we've recompiled asterisk with this option our servers are running
stable. Before the recompile we experienced crashes every couple of days.

A small test program I just made seems to verify that errno indeed is
thread local, but in that case a couple of questions remain:
- Why does adding -D_LIBC_REENTRANT seem to have solved our problems? (Ok,
this might be a coincidence, but if so it's a very big one).
- Why does to_number fail on the relatively small value of 1? Since
to_number is used without checking for errors this causes serious problems
(segfaults every couple of days).

I will run some further tests to see if I can come up with the answers,
but any help you can provide is greatly appreciated. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-22-08 02:42  ardjan         Note Added: 0087194                          
======================================================================