|Summary:||ASTERISK-14626: libc6/malloc/free abort of asterisk|
|Reporter:||Raimund Sacherer (hatrix)||Labels:|
|Date Opened:||2009-08-10 15:25:52||Date Closed:||2009-08-19 12:24:32|
|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
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.