Hi ,
I have a production system with below configuration…
Many times in a day Asterisk getting crashed and I’m getting below error message. Please guide me how to resolve this issue.
- Asterisk 11.19.0
- Dahdi 2.10.2
- Chan SS7 2.3.11
*** glibc detected *** /usr/sbin/asterisk: malloc(): memory corruption: 0x00007f8b6c0053d0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3c49075f3e]
/lib64/libc.so.6[0x3c4907a4fa]
/lib64/libc.so.6(__libc_calloc+0xcd)[0x3c4907a8cd]
/usr/sbin/asterisk(ast_frdup+0xc7)[0x4dfc67]
/usr/sbin/asterisk[0x47094f]
/usr/sbin/asterisk(ast_answer+0x324)[0x488cc4]
/usr/lib64/asterisk/modules/res_agi.so(+0x939b)[0x7f8c0176739b]
/usr/lib64/asterisk/modules/res_agi.so(+0xb4c4)[0x7f8c017694c4]
/usr/lib64/asterisk/modules/res_agi.so(+0xbc24)[0x7f8c01769c24]
/usr/lib64/asterisk/modules/res_agi.so(+0xd8d5)[0x7f8c0176b8d5]
Can you reproduce this on Asterisk 11.25.1?
If so, you will need to provide much more logging, and preferably backtraces from a non-optimised build.
Memory corruption normally happens a significant time before the crash, so details of the crash can be of very limited use.
HI David,
It’s production server, Its very difficult to upgrade the Asterisk on production server.
Is there any way to analyze the issue or any suggestion.
Analysing memory corruption is difficult, and is a waste of time if it turns out to have been fixed.
You could look at the change logs to see if there is a fix for a likely problem.
You should enable the highest logging level you tolerate and look for errors leading up to the crash - particularly warnings about locking issues. You are probably going to have to a good understanding of the source code for these to help.
You can look at the core dump, but that will be difficult if you did not build for debugging, the actual crash is likely to be in an unrelated part of the code, and you will, again, need a fairly deep understanding of the code to be able recognize any pattern in the corrupting data.
1 Like