[Home]

Summary:ASTERISK-05794: app_voicemail crashes when both Realtime voicemaand ODBC_STORAGE are enabled
Reporter:Cristian Alonso Aldama (cristiangafotas)Labels:
Date Opened:2005-12-07 09:22:23.000-0600Date Closed:2011-06-07 14:00:42
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) voicemcrash.txt
Description:I am testing the EXTENDED_ODBC_STORAGE facility in app_voicemail to store messages  in MySQL. I have tested this in both 1.2.0 and latest CVS.
If I configure extconfig.conf to read voicemail boxes from mysql with this line:
voicemail => mysql,asterisk,voicemail_users
and enable USE_ODBC_STORAGE and EXTENDED_ODBC_STORAGE in apps/Makefile * consistently crashes when calling Voicemail or VoicemailMain from the dialplan.

I have taken a look at issue 26402, which seems to be a similar (if not the same) problem, but tried recompiling unixODBC and MySQL without success. Maybe it is just a problem with my version of unixODBC+MySQL, but I have not been able to find a combination of the two that works.

See attached file "voicemcrash.txt" for further information (bt, cli log, detailed versions, table description, etc.)

Feel free to contact me for further details. I do not have IRC access, but will answer e-mail requests a.s.a.p.

****** ADDITIONAL INFORMATION ******

If I disable either realtime voicemail (and configure /etc/asterisk/voicemail.conf) or disable both USE_ODBC_STORAGE or EXTENDED_ODBC_STORAGE and reinstall app_voicemail  everything works as expected.
Crash is inside mysqlclient library when called from ODBC driver.

I am using Fedora Core 4 standard mysql libraries.
Attached file "voicemcrash.txt" contains backtrace, cli log and installed RPMs information.

Feel free to contact me for further details, I am kind of lost with this problem and it would be real nice to have all voicemail information inside the database.
Comments:By: Cristian Alonso Aldama (cristiangafotas) 2005-12-07 09:36:21.000-0600

My apologies for the typo in the title. It should read:
"app_voicemail crashes when both Realtime voicemail_users and ODBC_STORAGE are enabled"

By: Donny Kavanagh (donnyk) 2005-12-07 10:30:53.000-0600

did you edit voicemail.conf and add odbcstorage=?? where ?? = the database that contains the voicemessages table?

Granted this should not cause a segfault, but i believe the default within the code (i think i wrote this) is to use the database called 'asterisk' if it is not defined.

If this is infact the problem then i will look into submitting a patch to resolve it.

By: Cristian Alonso Aldama (cristiangafotas) 2005-12-07 10:39:04.000-0600

juggie, i did not have odbcstorage nor odbctable in the general section of voicemail.conf.
Tried adding both, but still crashes when calling voicemail or voicemailmain.

Besides, I am using default values for my database and voicemessages table (asterisk+voicemessages). No patch needed for that, i don't think that is the problem.

Thanks for your help.

By: Donny Kavanagh (donnyk) 2005-12-07 10:41:55.000-0600

does it work without odbc storage (but with realtime?)

By: Cristian Alonso Aldama (cristiangafotas) 2005-12-07 10:51:31.000-0600

Yes, it works with realtime without ODBC.



By: Cristian Alonso Aldama (cristiangafotas) 2005-12-07 10:59:25.000-0600

Well, this is getting strange but it seems I found a workaround:

If I start * with just "-g" argument, I am able to execute Voicemail and VoicemailMain without crashing.

If I start * with "-vvvg" or "-vvvgc" it crashes consistently when i execute Voicemail and VoicemailMain.

Same sources, same configuration, same machine.

My CLI log ends with
uniqueid => 2
customer_id => 0
context => Prueba
mailbox => 1223
password => 1234
fullname => Cristian Alonso: |1223|
email => a@b.com
stamp => 2005-12-07 11:47:07

before core is dumped. I will take a look at the code on Friday (i will not be able to read my e-mail tomorrow), to see if I can submit a patch. Any ideas will be apreciated.
Thanks again for your help.

By: Cristian Alonso Aldama (cristiangafotas) 2005-12-07 11:05:29.000-0600

My last note was not accurate. In fact, it was wrong:

when I start * without verbose mode it seems to be crashing less often, but still crashes sometimes. I will perform some tests as soon as possible and post the results, but * still crashes.

Maybe someone with privileges should change the Reproducibility to something different instead of "always".

Sorry, i really wanted to see it working :(

By: Cristian Alonso Aldama (cristiangafotas) 2005-12-09 04:37:19.000-0600

OK, just grabed another hard disk and reinstalled:
- CENTOS 4.2, which includes MySQL 4.1.12, unixODBC 2.2.9 and MyODBC 2.50.
- asterisk and asterisk-addons stable branch (1.2)

Enabled ODBC storage for voicemail and realtime voicemail_users from exconfig.conf. The rest of configuration is read statically from /etc/asterisk files.
Still seg faults when calling Voicemail or VoicemailMain.

I am currently compiling MyODBC version 3.51.12 from sources to try to debug it and see what is going on.

By: Cristian Alonso Aldama (cristiangafotas) 2005-12-09 07:27:15.000-0600

OK, finally it is working now. Nothing to blame inside * code, the short story is that libmyodbc was causing trouble (same problem described in issue 0002642)

Long story is that both Fedora Core 4 and CentOS with default unixODBC and MyODBC rpm's cause * to seg fault very often (almost always) when leaving a voice message when both Realtime voicemail and ODBC_STORAGE flags are used.

Both * 1.2 and latest CVS work perfectly with recompiled mysql-connector-odbc version 3.51.12 using configure parameters --disable-gui --enable-thread-safe.

So if you are using Fedora Core 4 or CentOS 4.2 with both realtime vm users and voicemessages ODBC_STORAGE in MySQL, I suggest you recompile libmyodbc and don't use MyODBC rpms.

Thanks juggie for your help, and sorry to everyone for the waste of time.

By: BJ Weschke (bweschke) 2005-12-10 10:49:52.000-0600

crash caused my external software. not an Asterisk issue. closing.