Summary:ASTERISK-13978: Core dump on high load , high dialplan MYSQL usage
Reporter:VoipForces (voipforces)Labels:
Date Opened:2009-04-17 11:16:43Date Closed:2011-06-07 14:00:47
Versions:Frequency of
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!