Summary: | ASTERISK-13978: Core dump on high load , high dialplan MYSQL usage | ||
Reporter: | VoipForces (voipforces) | Labels: | |
Date Opened: | 2009-04-17 11:16:43 | Date Closed: | 2011-06-07 14:00:47 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) bt.txt ( 1) bt2.txt ( 2) thread_apply_all_bt.txt ( 3) thread_apply_all_bt2.txt | |
Description: | Got a few core dumps on a high call volume and dialplan application that used a lot of mysql interaction using the MYSQL function. Right now I do not have a way to replicate as the core dumps are random. | ||
Comments: | By: VoipForces (voipforces) 2009-04-17 13:01:40 The same system was stable for over 1 hour that generated over 270 core dumps in less than maybe 30-40 minutes... I will generate an other backtrace from a random selection of those core dumps By: VoipForces (voipforces) 2009-04-17 14:17:46 Just added a other backtrace. There are some odd strings in there that seem to be coming from the astdb. However a "database show" looks normal. By: Clod Patry (junky) 2009-04-18 07:43:15 You should recompile your * with the DONT_OPTIMIZE flag (in the menuselect), to avoid gcc optimization (value optimized out). By: VoipForces (voipforces) 2009-04-22 16:11:11 Ok, Recompiled with DONT_OPTIMIZE and started asterisk with a fresh astdb and now it won't crashdump... Not sure what else to do. I did made a backup of the what I believe to be a corrupted astdb... By: Leif Madsen (lmadsen) 2009-05-22 14:08:01 Most of these issues tend to fall back down into the MySQL libraries being used. I've had these issues with other customers and I moved them to using res_odbc and func_odbc to replace the MYSQL() application, and then their crashes go away. By: VoipForces (voipforces) 2009-05-26 15:36:18 Sorry for the delay. The crashes were actually caused by a corrupted astdb. Recraeted the astdb and been no crash since... By: Leif Madsen (lmadsen) 2009-05-26 16:13:42 Closed per the reporter. Thanks for following up! |