Segmentation Fault

Home » Asterisk Users » Segmentation Fault
Asterisk Users 7 Comments

I tested this issue with version 13 and version 18.

In res_odbc.conf, if I add a second, new data source like

[asterisk]

enabled=yes

dsn=asterisk

sanitysql => select 1

isolation => read_committed

username=root

;password pre-connect => yes

forcecommit => yes

connect_timeout => 10

negative_connection_cache => 0

max_connections =>500

my odbc.ini

[cdr]

Description = MySQL ODBC Driver Testing

Driver = maria

Socket = /var/run/mysqld/mysqld.sock

User = root

Password Database = public

Option = 3

I get, immediately, segmentation fault.

With only one, it works fine.

Is this by design?

Philip

7 thoughts on - Segmentation Fault

  • You should be able to define multiple data sources. However I’m having my own issues. I have my dialplan accessing one maria database which is hosted locally on the asterisk server then logging cdr with odbc adaptive which connects to maria on a remote machine. This works fine except when the remote server is out of reach the calls zombie and eventually lead to a fault. The cli imply that the calls hang on SET(CDR_PROP(disable)=1) which is ironic since instructing the system not to connect to the cdr server appears to cause the problem and there may be a defect in the adaptive_odbc implementation where it somehow still communicates with the server during the cdr_func(disable). My experimentation suggests that the maria_odbc driver utilizes a single thread (there are odbc directives to adjust this –
    but it seems they have been superseded).

  • Setting “batch=yes” in your /etc/asterisk/cdr.conf file may fix this by moving the database interaction to separate threads away from the call.

  • moving the database interaction to separate threads away from the call.

    I can certainly try this, but I believe the maria-odbc-driver is what is running as a single thread. Its been a few months since I played with this, I think there may also be a compiled in parameter in the unixodbc regarding threading that’s default value was changed in recent years.

    The only asterisk issue is why it would hang at SET(CDR_PROP(disable)=1)?
    Perhaps there is an interaction where odbc_adaptive always checks an aspect of the tables it interacts with (and needlessly when disabling cdr). I
    started looking at the source – but got pulled onto another project before I was able to determine anything, and have not revisited the issue. So for me this isn’t current but just me throwing in my recollections that may pertain to Federico’s issue.

  • There’s nothing explicitly written to prevent such a thing within Asterisk itself. There is no backtrace here so nothing to show where the crash actually occurred, be it Asterisk itself or UnixODBC. If UnixODBC we’re a somewhat simple user of it, so specific configuration of it or its build may be the source of it.

  • Hi Federico,

    Segfaults are 100% not by design.  Typically if something seg faulted, either there is a logic bug or a component mismatch. The you should definitely be able to use more than one connection (we use multiple connections with postgres odbc with no issue).

    If Asterisk segfaults when using odbc Try this:
    – use ps and get the pid of Asterisk
    – run gdb, attach to the asterisk pid
    – do something that would cause the seg fault
    – get a backtrace (bt) and show all threads backtrace (thread apply all bt)

    if Asterisk segfaults when starting up Run Asterisk straight from gdb Wait for segfault, get backtrace, and all threads backtrace

  • I cannot follow your instructions, because asterisk segfaults on start. It never starts

    Can you give me instruction to trap this segfault on starting asterisk?

    Like gdb …..asterist –gvvvvvvc

    From: asterisk-users I tested this issue with version 13 and version 18.

    In res_odbc.conf, if I add a second, new data source like

    [asterisk]

    enabled=yes

    dsn=asterisk

    sanitysql => select 1

    isolation => read_committed

    username=root

    ;password=

    pre-connect => yes

    forcecommit => yes

    connect_timeout => 10

    negative_connection_cache => 0

    max_connections =>500

    my odbc.ini

    [cdr]

    Description = MySQL ODBC Driver Testing

    Driver = maria

    Socket = /var/run/mysqld/mysqld.sock

    User = root

    Password =

    Database = public

    Option = 3

    I get, immediately, segmentation fault.

    With only one, it works fine.

    Is this by design?

    Philip

  • Hi Federico,

    The first hit from Google ‘how to run command from gdb’
    https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_5.html#:~:text=Use%20the%20run%20command%20to,section%20Commands%20to%20specify%20files).

    # gdb
    (gdb) file /usr/sbin/asterisk
    (gdb) run –gvvvvvvc Starting program: /usr/sbin/asterisk -gvvvvvc
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
    ….snip…. Created by Mark Spencer
    Asterisk comes with ABSOLUTELY NO WARRANTY; type ‘core show warranty’
    for details.
    ….snip…

    etc etc