| 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 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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: [default] mode=files directory=/var/lib/asterisk/moh 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. https://issues.asterisk.org/view.php?id=15109#108551 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! best 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. | ||