[asterisk-dev] Recent UnixODBC Issues

Joshua Colp jcolp at digium.com
Thu Jun 2 11:35:16 CDT 2016


Kia ora,

As many of you are aware (and for those who aren't) as part of Asterisk
13.8 changes went into the res_odbc module to more heavily leverage
UnixODBC connection management and pooling capabilities. Previously we
would use only a single connection to the database. Since this has been
released many individuals have reported crashes and apparent deadlocks
as a result of this change. We've been investigating and have some
information we'd like to share so everyone can be aware of where things
stand and where we can use some help.

These overall crashes have been a result of issues within both the
database connectors themselves and UnixODBC.

For database connectors old versions seem to have issues with unicode
support within UnixODBC and with the threading constraints now placed
upon them by using multiple connections heavily. Using the latest
versions has resolved these specific crashes for people.

For the UnixODBC crash the problem occurs at disconnect due to
inadequate thread protection around critical environment data. This was
fixed as of UnixODBC 2.3.2. Unfortunately distros may be shipping old
versions causing the problem to be present for many individuals.

The apparent deadlock appears to be due to a regression introduced in
UnixODBC 2.3.3 in configuration caching. This has resulted in the cache
not being used and also in the cache growing out of control. For each
connection request the configuration is cached again in a linked list.
As the number of connections grow this list grows longer and longer
taking longer to iterate. While the cache has a 20 second expiration at
heavy connection use it's still not enough to combat the growth. This
issue has been reported upstream[1] and is on its way to being fixed in
UnixODBC itself.

To help confirm some of these we'd like people to try (if your
environment allows you) a combination of UnixODBC 2.3.2 and the latest
version of their database connector. This will allow us to confirm some
of the above information in more environments and to see if any other
issues may occur.

Thank you for your help!

Cheers,

[1] http://mailman.unixodbc.org/pipermail/unixodbc-dev/2016-June/001890.html

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list