Core dump gets created while accessing voicemail

Asterisk Asterisk Support
1

Hi ALL,

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.

asterisk 1.4.22.1
odbc storage of voicemail messages
centos 5.2 64bit
unixODBC-2.2.11-7.1
mysql-connector-odbc-3.51.12-2.2
mysql-server-5.0.45-7.el5

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/libodbc.so.1
#1 0x000000322b417b5c in SQLFreeHandle () from /usr/lib64/libodbc.so.1
#2 0x00002aaabd36ecdd in message_exists (dir=, msgnum=) from /usr/lib/asterisk/modules/app_voicemail.so
#3 0x00002aaabd36fab2 in save_to_folder (vmu=0x4177ce80, vms=, msg=1, box=)
from /usr/lib/asterisk/modules/app_voicemail.so
#4 0x00002aaabd36fc77 in close_mailbox (vms=0x41776d60, vmu=0x4177ce80) from /usr/lib/asterisk/modules/app_voicemail.so
#5 0x00002aaabd383b43 in vm_execmain (chan=0x2aaaac244d50, data=) from /usr/lib/asterisk/modules/app_voicemail.so
#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/libpthread.so.0
#11 0x000000322a4d1ded in clone () from /lib64/libc.so.6

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

Thanks in advance.

vimurli

2

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 issues.asterisk.org. 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.