Asterisk crashes on realtime with libc-2.17.so

Hello,

we have an Asterisk 16.9.0 in a Centos 7.
After setting up realtime for ps_endpoint, ps_contacts, etc. and restart the asterisk service, it crashes.
The odbc driver is → mysql-connector-odbc-5.3.14-linux-el7-x86-64bit

The configuration of the odbc.ini, etc is ok but as soon as res_odbc.so is loaded it crashes.

This is the log:

 asterisk[26472]: segfault at 1010070 ip 00007f25729a166e sp 00007ffdd2731980 error 4 in libmyodbc5w.so

We’re not sure what would be the proper version of the odbc driver to get this working or at least not crashing Asterisk.

Can you help us with that please?.

Many thanks !!!
Richi

https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

Also, for crashes, you are likely to need the logs that Asterisk, itself, produces, leading up to the crash. The initial cause of the crash may happen some time before the crash.

I got more data.

We can start Asterisk with realtime setup as long as we don’t load the res_odbc module. As soon as we load that module Asterisk crashes:

a2*CLI> module load res_odbc
a2*CLI>
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups

And this is the dmesg log

[195056.829810] asterisk[12391]: segfault at 0 ip 00007f265b9e1016 sp 00007f25a3fc27f8 error 4 in libc-2.17.so[7f265b8a3000+1c2000]

It doesn’t look like a problem with ODBC it self because we are able to do a:

isql sipodbc -v
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL>

Looks like smth is wrong with the res_odbc module.

Thanks for your help with this :wink:

You can get crashes on Load if the Asterisk core was compiled with different versions or options, from those used for the module.

David … we’re trying to get the Backtrace using

/var/lib/asterisk/scripts/ast_coredumper --latest

but it takes so long that we don’t even know if it’s doing smth.
The core is 109M … how long it would normally take to process it?

In the directory we just can see a .ast_coredumper.gdbinit, not any .txt yet

I’ve always done it manually, directly issuing gdb commands, and the actual processing time is quite short. I wouldn’t expect the script to take more than a few seconds to run, but I’ve run it on systems where all the files are probably still in the cache.

It’s solved !!

I’m leaving here the solution.

The problem was the mysql-odbc-connector. The version really installed was the mysql-connector-odbc-5.2.7 one.
We uninstall that one and install mysql-connector-odbc-8.0.23-1.el7.x86_64.rpm with:

rpm -Uvh mysql-connector-odbc-8.0.23-1.el7.x86_64.rpm

Then the res_odbc.so was loaded properly.

Thanks for your feedback !!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.