ABE-1628 and RYM-150398 and AST-103 in internal Digium
bug trackers.
These fixes address a really subtle memory corruption
problem that would happen in machines heavily loaded
in production environments. The corruption would
always take the form of the STMT object getting
nulled out and one of the unixODBC calls would
crash trying to access statement->connection.
It isn't fully proven yet, but the server has
now been running 2.5 days without appreciable
memory growth, or any gain of %cpu, and no
crashes. Whether this is the problem or not
on that server, these fixes are still warranted.
As it turns out, **I** introduced these errors
unwittingly, when I corrected another crash earlier.
I had formed the build_query routine, and failed
to remove mutex_unlock calls in 3 places in the
transplanted code. These unlocks would only
happen in error situations, but unlocking the
mutex early set the code up for a catastrophic
failure, it appears. It would happen only once
every 100K-200K or more calls, under heavy load...
but that is enough.
If another crash occurs, with the same MO,
I'll come back and remove my confession from the log, and
we'll keep searching, but the fact that we
have Asterisk dying from an asynchronous
wiping of the STMT object, only on some connection
error, and that the server has lived for 2.5
days on this code without a crash, sure make
it look like this was the problem!
Also, in several points, Statement handles are
set to NULL after SQLFreeHandle. This was mainly
for insurance, to guarantee a crash. As it turns
out, the code does not appear to be attempting
to use these freed pointers.
Asterisk owes a debt of gratitude to Federico Alves
and Frediano Ziglio for their untiring efforts in
finding this bug, among others.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was not getting set in the STMT; it was coming out,
usually, as binary garbage to an mssql server.
These changes fixed the problem. The only thing
I can venture forth as a guess, is that the pointer
is being stored in the interface, not a copy of the
string. Because we ripped the build process into a
subroutine, the timestr became a temp. stack variable,
and between the time the STMT got built and the
time it was executed on the server, the string being
pointed to was damaged. At any rate, even if this
theory is false, and some mechanism was at fault,
this fix worked reliably where it didn't before.
Why this bug didn't bite last week, I have no idea.
This change basically defines the timestr buffer
in the calling function, extending the life of the
buffer to cover both the STMT's building and
processing to the server.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
now reports AST_MODULE_LOAD_DECLINE when loading if config file
is not there, also fixed an error in res_config_pgsql where it
had a non static function when it should.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
remove resetting of variables during unload that will only be freed or set to known values on reload
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@6085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
