[Home]

Summary:ASTERISK-09313: ODBC produces Segmentation Fault
Reporter:fugitivo (fugitivo)Labels:
Date Opened:2007-04-25 13:22:26Date Closed:2011-06-07 14:00:37
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace.txt
Description:Using ODBC to store voicemail in a PostgreSQL database results in a segmentation fault and crash of asterisk 1.4.1.
I've added a debug line to check if parameters are ok (DIR and MSGNUM).
It seems that the problem is when replacing parameters with the function
SQLBindParameter, but I don't know if it's a bug in asterisk or my installed odbc version.
I found issue # 0006946 similar to this, but it's closed.
Attached is a backtrace

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

Asterisk ODBC show:
*CLI> odbc show
Name: Proyecto
DSN: Proyecto
Pooled: no
Connected: yes


Asterisk CLI when error occurs:

[Apr 25 14:46:00] WARNING[9279]: app_voicemail.c:1268 delete_file: DIR: /var/spool/asterisk/voicemail/default/1234/INBOX  -  MSGNUM: 0

[Apr 25 14:46:00] WARNING[9279]: app_voicemail.c:1281 delete_file: SQL Execute error!
[DELETE FROM voicemessages WHERE dir=? AND msgnum=?]

 == Parsing '/var/spool/asterisk/voicemail/default/1234/INBOX/msg0000.txt': Found
Length is 2046
Segmentation fault


app_voicemail.c related code:

               snprintf(sql, sizeof(sql), "DELETE FROM %s WHERE dir=? AND msgnum=?",odbc_table);
               res = SQLPrepare(stmt, (unsigned char *)sql, SQL_NTS);
               if ((res != SQL_SUCCESS) && (res != SQL_SUCCESS_WITH_INFO)) {
                       ast_log(LOG_WARNING, "SQL Prepare failed![%s]\n", sql);
                       SQLFreeHandle (SQL_HANDLE_STMT, stmt);
                       ast_odbc_release_obj(obj);
                       goto yuck;
               }
               SQLBindParameter(stmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_CHAR, strlen(sdir), 0, (void *)sdir, 0, NULL);
               SQLBindParameter(stmt, 2, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_CHAR, strlen(msgnums), 0, (void *)msgnums, 0, NULL);
               res = ast_odbc_smart_execute(obj, stmt);
               if ((res != SQL_SUCCESS) && (res != SQL_SUCCESS_WITH_INFO)) {
                       ast_log(LOG_WARNING, "SQL Execute error!\n[%s]\n\n", sql);
                       SQLFreeHandle (SQL_HANDLE_STMT, stmt);
                       ast_odbc_release_obj(obj);
                       goto yuck;
               }


/etc/odbc.ini:

[Proyecto]
Description           = Desarrollo PostgreSQL
Driver                = Proyecto
Trace                 = No
TraceFile             =
Database                = proyecto
Servername              = 192.168.0.107
UserName                = postgres
Password                =
Port                    = 5432
Protocol                = 8.1
ReadOnly                = No
RowVersioning           = No
ShowSystemTables        = No
ShowOidColumn           = No
FakeOidIndex            = No
ConnSettings            =

/etc/odbcinst.ini:

[Proyecto]
Description     = PostgreSQL ODBC driver
Driver          = /usr/lib/odbc/psqlodbca.so
Setup           = /usr/lib/odbc/libodbcpsqlS.so
Debug           = 1
CommLog         = 1
UsageCount      = 2


/etc/asterisk/res_odbc.conf:

[Proyecto]
enabled => yes
dsn => Proyecto
username => postgres
pre-connect => yes


Comments:By: Tilghman Lesher (tilghman) 2007-04-25 13:48:32

This would appear to be a bug in the Postgres libraries.  Please report this issue to them.  We will keep this bug open for a few days for coordination.
By: fugitivo (fugitivo) 2007-04-25 14:06:26

Corydon, how does this appear to be a bug in the Postgres libraries? Using Postgres directly and using isql works OK. Maybe you mean a bug in odbc-postgresql driver?
By: Tilghman Lesher (tilghman) 2007-04-25 16:41:19

You're quite right.  This could also be a bug in the Postgres ODBC driver; however, since it is 3 levels deep into the libpq library, I suspect the bug is there.
By: Tilghman Lesher (tilghman) 2007-04-25 16:58:31

Odd, I'm looking in the last three versions of psqlodbc and neither version calls lo_creat().  Sounds like you just need to upgrade, as this bug has probably already been fixed.


By: fugitivo (fugitivo) 2007-04-26 12:42:42

Corydon, indeed upgrading psqlodbc seems to work, but there's another issue. Please tell me if I need to open a new one.


Asterisk CLI:

[Apr 26 12:46:25] WARNING[23669]: app_voicemail.c:1268 delete_file: DIR: /var/spool/asterisk/voicemail/default/1234/INBOX  -  MSGNUM: 0

[Apr 26 12:46:25] WARNING[23669]: app_voicemail.c:1281 delete_file: SQL Execute error!
[DELETE FROM voicemessages WHERE dir=? AND msgnum=?]

 == Parsing '/var/spool/asterisk/voicemail/default/1234/INBOX/msg0000.txt': Found
Length is 3498
[Apr 26 12:46:25] WARNING[23669]: res_odbc.c:147 ast_odbc_smart_execute: SQL Execute returned an error -1: HY000: Could not commit (in-line) a transaction (40)
[Apr 26 12:46:25] WARNING[23669]: res_odbc.c:147 ast_odbc_smart_execute: SQL Execute returned an error -1: 00000: Could not commit (in-line) a transaction (40)
[Apr 26 12:46:25] WARNING[23669]: app_voicemail.c:1441 store_file: SQL Execute error!
[INSERT INTO voicemessages (dir,msgnum,recording,context,macrocontext,callerid,origtime,duration,mailboxuser,mailboxcontext) VALUES (?,?,?,?,?,?,?,?,?,?)]

[Apr 26 12:46:25] WARNING[23669]: res_odbc.c:147 ast_odbc_smart_execute: SQL Execute returned an error -1: HY000: ERROR:  current transaction is aborted, commands ignored until end of transaction block;
Error while executing the query (120)
[Apr 26 12:46:25] WARNING[23669]: res_odbc.c:147 ast_odbc_smart_execute: SQL Execute returned an error -1: 00000: ERROR:  current transaction is aborted, commands ignored until end of transaction block;
Error while executing the query (120)
[Apr 26 12:46:25] WARNING[23669]: app_voicemail.c:2336 messagecount: SQL Execute error!
[SELECT COUNT(*) FROM voicemessages WHERE dir = '/var/spool/asterisk/voicemail/default/1234/INBOX']

[Apr 26 12:46:25] WARNING[23669]: app_voicemail.c:2342 messagecount: SQL Fetch error!
[SELECT COUNT(*) FROM voicemessages WHERE dir = '/var/spool/asterisk/voicemail/default/1234/INBOX']


Postgres LOG:

ERROR:  invalid large-object descriptor: 48
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block


What Postgresql documentation says about that error:

You need to put BEGIN WORK and COMMIT around any use of a large object handle, that is, surrounding lo_open ... lo_close. CurrentLY POSTGRESQL enforces the rule by closing large object handles at transaction commit. So the first attempt to do anything with the handle will draw invalid large obj descriptor. So code that used to work (at least most of the time) will now generate that error message if you fail to use a transaction.

If you are using a client interface like ODBC you may need to set auto-commit off.  

http://www.postgresql.org/files/documentation/books/aw_pgsql/node196.html#SECTION0029923000000000000000



It seems PostgreSQL needs auto-commit set to OFF before working with large objects.
By: Tilghman Lesher (tilghman) 2007-04-26 12:53:33

You should have opened another one, but again, this is the driver's fault.  If you need to wrap the query in a transaction to make it work, then that should be handled by the ODBC driver, since that is not required by any other backend driver.