Core dump gets created while accessing voicemail


When i was accessing the voice message it suddenly goes dead and after that i couldn’t able to retrieve the voicemessage again from my mailbox . This happens once in a while for any configured mailboxes

I am using the following system configuration.

odbc storage of voicemail messages
centos 5.2 64bit

Following are the traces i found while troubleshooting the issue.

  1. I found a .lock file created in the INBOX folder of my mailbox
  2. The following core dump gets created during the first time the voicemessage access got failed.

(gdb) bt
#0 0x000000322b417649 in SQLFreeEnv () from /usr/lib64/
#1 0x000000322b417b5c in SQLFreeHandle () from /usr/lib64/
#2 0x00002aaabd36ecdd in message_exists (dir=, msgnum=) from /usr/lib/asterisk/modules/
#3 0x00002aaabd36fab2 in save_to_folder (vmu=0x4177ce80, vms=, msg=1, box=)
from /usr/lib/asterisk/modules/
#4 0x00002aaabd36fc77 in close_mailbox (vms=0x41776d60, vmu=0x4177ce80) from /usr/lib/asterisk/modules/
#5 0x00002aaabd383b43 in vm_execmain (chan=0x2aaaac244d50, data=) from /usr/lib/asterisk/modules/
#6 0x0000000000481e2d in pbx_extension_helper (c=0x2aaaac244d50, con=, context=0x2aaaac244fa0 “staff-international”,
exten=0x2aaaac244ff0 “*97”, priority=106, label=, callerid=0x1a2cd5c0 “1355”, action=E_SPAWN) at pbx.c:537
#7 0x0000000000483b66 in __ast_pbx_run (c=0x2aaaac244d50) at pbx.c:2317
#8 0x0000000000484849 in pbx_thread (data=0x322b663b40) at pbx.c:2621
#9 0x00000000004aef5c in dummy_start (data=) at utils.c:912
#10 0x000000322b006307 in start_thread () from /lib64/
#11 0x000000322a4d1ded in clone () from /lib64/

Can any one please help me to trace down the issue using the core dump.

Thanks in advance.


You need to rebuild with the no-optimize option. Also, unless you can produce a debug version of the ODBC code, you’ll need a bt full, to show the local variables from which the bad parameter was derived.

Generally you need to follow the procedure in doc/backtrace.c and submit to However, as 1.4.22 is getting quite old now, you should first check if it is already fixed.

I presume this was signal 11, but that fact would also be useful.