[asterisk-bugs] [JIRA] (ASTERISK-26054) Asterisk crashes (core dump)

[Etienne Lessard (JIRA)]

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

Etienne Lessard commented on ASTERISK-26054:
--------------------------------------------

Indeed, updating both unixodbc and psqlodbc to the latest available versions has fixed the issue, i.e. it is not crashing with memory corruption anymore. I don't know if updating both unixodbc and psqlodbc was strictly necessary, or just updating unixodbc would have been sufficient. Anyway, sorry for the noise.

That said, my tests seems to show that there's a new memory leak between Asterisk 13.7 and Asterisk 13.9. I'm already aware of ASTERISK-25262, but when I compare the memory usage from our 13.7 tests with our 13.9 tests, the rate at which memory is consumed by asterisk has grown between these 2 versions. Now, the question is, who's the culprit... (I hope it's not the updated ODBC libraries...). Someone is aware of it ?

@Davis since you are also using ODBC, I'm assuming you have a similar issue. You should try either to update unixodbc and your mysql ODBC driver, or stop using ODBC from asterisk and see if it still crashes.

> Asterisk crashes (core dump)
> ----------------------------
>
>                 Key: ASTERISK-26054
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26054
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/cdr_custom
>    Affects Versions: 13.9.1
>         Environment: cat /etc/*release*
> SHMZ release 6.6 (Final)
> SHMZ release 6.6 (Final)
> SHMZ release 6.6 (Final)
> SHMZ release 6.6 (Final)
> cpe:/o:schmooze:linux:6:GA
> lscpu
> Architecture:          x86_64
> CPU op-mode(s):        32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                24
> On-line CPU(s) list:   0-23
> Thread(s) per core:    2
> Core(s) per socket:    6
> Socket(s):             2
> NUMA node(s):          2
> Vendor ID:             GenuineIntel
> CPU family:            6
> Model:                 63
> Stepping:              2
> CPU MHz:               2399.943
> BogoMIPS:              4799.33
> Virtualization:        VT-x
> L1d cache:             32K
> L1i cache:             32K
> L2 cache:              256K
> L3 cache:              15360K
> NUMA node0 CPU(s):     0-5,12-17
> NUMA node1 CPU(s):     6-11,18-23
>  vmstat
> procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
>  1  0      0 224716 241680 30706788    0    0     0     3    1    1  0  0 100  0  0
>            Reporter: B. Davis
>            Assignee: B. Davis
>            Severity: Critical
>         Attachments: backtrace.txt
>
>
> New installation, CDR records stored on external database over a dedicated network interface, system appears to run fine and then randomly once every day or two has a core dump. 
> System operates with about 100-180 active calls w/ about 250-300 channels open.
> System has 32GB RAM and ram shows as mostly cashed.
> Attached is the backtrace.



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