Summary:ASTERISK-14626: libc6/malloc/free abort of asterisk
Reporter:Raimund Sacherer (hatrix)Labels:
Date Opened:2009-08-10 15:25:52Date Closed:2009-08-19 12:24:32
Versions:Frequency of
Environment:Attachments:( 0) backtrace_200908102203.txt
Description:I am not definitly sure on how to describe this crash, as, obviosly it is not really a crash as it's not a segfault so much than a controlled abort, as you can see in the backtrace.

As it has something to do with music_on_hold (as seen in the backtrace) it may be associated with bug ASTERISK-1501195

The /etc/asterisk/musiconhold.conf is:


the /var/lib/asterisk/moh contains this files:
-rw-r--r--  1 asterisk asterisk    0 2009-07-30 21:12 .asterisk-moh-freeplay-wav
-rw-r--r--  1 root     root        0 2009-04-01 18:28 CHANGES-asterisk-moh-freeplay-wav
-rw-r--r--  1 root     root     1.9M 2009-04-01 18:28 fpm-calm-river.wav
-rw-r--r--  1 root     root     2.5M 2009-04-01 18:28 fpm-sunshine.wav
-rw-r--r--  1 root     root     2.2M 2009-04-01 18:28 fpm-world-mix.wav
-rw-r--r--  1 root     root      184 2006-06-13 22:29 LICENSE-asterisk-moh-freeplay-wav

whatever the .asterisk-moh-freeplay-wav is.

No information in the full-log, to be fair we have high logging not activated in production as it drains IO and ressources. As it is not a segfault there are no Logs in kern.log or syslog

If you need any more information please tell and i'l be happy to provide.
Comments:By: David Brillert (aragon) 2009-08-10 23:17:41

Bug 15109 was opened and determined to be a memory abort when using moh files based mode. I have done lots of work to try and reproduce under Valgrind but Asterisk will not crash under Valgrind in this scenario.

I recommend you follow these instructions and try tilghman's Asterisk patch to capture memory issues without having to run Asterisk under Valgrind.

I hope you can attempt this soon because it will be at least a week until I will have an opportunity to try tilghman's work on malloc_hold and get this problem fixed.  This issue is blocking the release of 1.4.27 and preventing me from upgrading a few mission critical sites.

By: Raimund Sacherer (hatrix) 2009-08-11 02:04:25

Hi Aragon,

i really need this fixed as well, my problem is, as I stated as a note in the other bug, I can not reproduce it (at least reliable) in my testlab, the servers there are running happily, it might be that my testszenarios are only clients calling agents as I did not have time to figure out how to make call transfers in a scripted mode (like with sipp, i am doing all my testing with sipp scripting, but as I am fairly new to asterisk/voip/sip the call transfer gives me a bit of an headache).

So If you can tell me how you reproduce this bug in the Lab, i will happily stress test it!


By: Amilcar S Silvestre (amilcar) 2009-08-12 19:14:01

Related or duplicate of 15109.

By: David Brillert (aragon) 2009-08-19 08:36:01

I just uploaded a valgrind crash debug to 15109
The output looks good I think....

We'll see what the developers think.

By: Jason Parker (jparker) 2009-08-19 12:24:17

I'm going to close this as a duplicate of ASTERISK-14129.  Please continue discussions there.