[asterisk-bugs] [JIRA] (ASTERISK-23475) res_odbc crash

[Tobias Gunkel (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216925#comment-216925 ] 

Tobias Gunkel commented on ASTERISK-23475:
------------------------------------------

I think this issue can be closed. No more crashes since upgrade to unixODBC-2.3.2. Thank you for your help!

> res_odbc crash
> --------------
>
>                 Key: ASTERISK-23475
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23475
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_odbc
>    Affects Versions: 1.8.26.0, 11.8.0
>         Environment: Linux Kernel 3.12.9 x86_64, 2 x Intel Xeon CPU E5530 (16 cores overall)
>            Reporter: Tobias Gunkel
>            Assignee: Tobias Gunkel
>         Attachments: backtrace_20140310.txt, backtrace_20140311.txt
>
>
> Hi,
> we're running a rather heavy load setup with approximately 200-500 calls per minute on one server (average).
> Since we switched from MYSQL() to res_odbc we ran into sporadic Asterisk crashes (about 3 times a day). Those crashes are not necessarily bound to cpu load. It happens at 40% cpu-idle as well as 95% cpu-idle.
> The last output from "asterisk-rcgvv" after the crash is always:
> NOTICE[433]: res_odbc.c:1563 odbc_obj_connect: res_odbc: Connected to asterisk [asterisk]
> I've uploaded two backtraces:
> http://pastebin.com/4M9jrc3g
> http://pastebin.com/Te5z6kkb
> All phone numbers were substituted with 0123456789.
> Our /etc/asterisk/res_odbc.conf looks like this:
> [asterisk]
> enabled => yes
> dsn => asterisk
> username => asterisk
> password => ***
> pooling => yes
> limit => 100
> pre-connect => yes
> sanitysql => set wait_timeout = 86400
> idlecheck => 1800
> share_connections => yes
> negative_connection_cache => 120
> [asteriskIB]
> enabled => yes
> username => asterisk
> dsn => asteriskIB
> password => ***
> pooling => yes
> limit => 50
> pre-connect => yes
> sanitysql => select 1
> idlecheck => 1800
> share_connections => yes
> negative_connection_cache => 120
> Switching back to MYSQL() immediately fixes the problem.
> Any help in debugging this issue would be greatly appreciated!
> Best regards,
> Tobias



--
This message was sent by Atlassian JIRA
(v6.2#6252)