[asterisk-bugs] [Asterisk 0017084]: [patch] Asterisk crash in func_odbc

Tue May 11 05:50:38 CDT 2010

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17084 
====================================================================== 
Reported By:                falves11
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17084
Category:                   Channels/General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     ready for review
Asterisk Version:           SVN 
JIRA:                       SWP-1162 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 253802 
Request Review:              
====================================================================== 
Date Submitted:             2010-03-23 12:46 CDT
Last Modified:              2010-05-11 05:50 CDT
====================================================================== 
Summary:                    [patch] Asterisk crash in func_odbc
Description: 
I am attaching the GDB backtrace
====================================================================== 

---------------------------------------------------------------------- 
 (0121691) wdoekes (reporter) - 2010-05-11 05:50
 https://issues.asterisk.org/view.php?id=17084#c121691 
---------------------------------------------------------------------- 
Are you sure this does not happen on 1.4?

On database errors (can happen when when DROPping/reCREATing a view or
function for example), it is possible that one thread is calling
SQLFreeHandle while another calls e.g. SQLDescribeCol:

(gdb) thread 4
[Switching to thread 4 (Thread 0x420c4950 (LWP
5615))]https://issues.asterisk.org/view.php?id=0 
0x00007f7db60e8ced in SQLDescribeCol () from /usr/lib/libodbc.so.1
(gdb) bt 
https://issues.asterisk.org/view.php?id=0  0x00007f7db60e8ced in SQLDescribeCol
() from /usr/lib/libodbc.so.1
https://issues.asterisk.org/view.php?id=1  0x00007f7db44d2535 in realtime_odbc
(database=<value optimized out>,
table=<value optimized out>, ap=<value optimized out>) at
res_config_odbc.c:181
https://issues.asterisk.org/view.php?id=2  0x000000000044d304 in
ast_load_realtime (family=<value optimized out>)
at config.c:1435
https://issues.asterisk.org/view.php?id=3  0x00007f7da14f37a0 in realtime_peer
(newpeername=0x420c3b80
"040055001", sin=0x0, devstate_only=1) at chan_sip.c:2660
https://issues.asterisk.org/view.php?id=4  0x00007f7da14f9527 in sip_devicestate
(data=<value optimized out>) at
chan_sip.c:17270
https://issues.asterisk.org/view.php?id=5  0x000000000045291a in
ast_device_state (device=0x9dc3f8
"SIP/040055001") at devicestate.c:170
https://issues.asterisk.org/view.php?id=6  0x0000000000452d7e in
do_devstate_changes (data=<value optimized out>)
at devicestate.c:285
https://issues.asterisk.org/view.php?id=7  0x00000000004b6edc in dummy_start
(data=<value optimized out>) at
utils.c:856
https://issues.asterisk.org/view.php?id=8  0x00007f7dbb105fc7 in start_thread ()
from /lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=9  0x00007f7db81485ad in clone () from
/lib/libc.so.6
https://issues.asterisk.org/view.php?id=10 0x0000000000000000 in ?? ()
(gdb) thread 11
[Switching to thread 11 (Thread 0x407a0950 (LWP
5628))]https://issues.asterisk.org/view.php?id=0 
0x00007f7dbb10c384 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
https://issues.asterisk.org/view.php?id=0  0x00007f7dbb10c384 in __lll_lock_wait
() from /lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=1  0x00007f7dbb107bf0 in _L_lock_102 ()
from /lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=2  0x00007f7dbb1074fe in
pthread_mutex_lock () from /lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=3  0x00007f7db60ee76f in ?? () from
/usr/lib/libodbc.so.1
https://issues.asterisk.org/view.php?id=4  0x00007f7db60eedec in SQLFreeHandle
() from /usr/lib/libodbc.so.1
https://issues.asterisk.org/view.php?id=5  0x00007f7db63355a2 in
odbc_obj_disconnect (obj=0x9a2820) at
res_odbc.c:509
https://issues.asterisk.org/view.php?id=6  0x00007f7db63371e2 in
ast_odbc_prepare_and_execute (obj=0x9a2820,
prepare_cb=0x7f7daaf53400 <generic_prepare>, data=0x40797c20) at
res_odbc.c:124
https://issues.asterisk.org/view.php?id=7  0x00007f7daaf5368f in acf_odbc_read
(chan=0x9d95b0, cmd=<value
optimized out>, s=0x40798430 "", buf=0x407988d0 "", len=4096) at
func_odbc.c:278
https://issues.asterisk.org/view.php?id=8  0x0000000000485578 in
pbx_substitute_variables_helper_full
(c=0x9d95b0, headp=0x9d99e8, cp1=<value optimized out>, cp2=0x4079da3b "",
count=8132) at pbx.c:1691
https://issues.asterisk.org/view.php?id=9  0x00000000004875cf in
pbx_extension_helper (c=0x9d95b0, con=<value
optimized out>, context=0x9d9800 "pi_phone_account_cont", exten=0x9d9850
"333", priority=2, label=0x0, callerid=0x9dc530 "040055001",
action=E_SPAWN) at pbx.c:1786
https://issues.asterisk.org/view.php?id=10 0x000000000048856a in __ast_pbx_run
(c=0x9d95b0) at pbx.c:2300
https://issues.asterisk.org/view.php?id=11 0x0000000000489ea9 in pbx_thread
(data=0x7f7db6333d60) at pbx.c:2621
https://issues.asterisk.org/view.php?id=12 0x00000000004b6edc in dummy_start
(data=<value optimized out>) at
utils.c:856
https://issues.asterisk.org/view.php?id=13 0x00007f7dbb105fc7 in start_thread ()
from /lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=14 0x00007f7db81485ad in clone () from
/lib/libc.so.6
https://issues.asterisk.org/view.php?id=15 0x0000000000000000 in ?? ()

See the attached asterisk-1.4.31-gdb.txt.

I'm using unixodbc 2.2.11-16 with libmyodbc 3.51.15r409-4.

Using pooling=>yes fixes the issue.

I guess the comment in res_odbc.c is right and there is a race:
/*
* While this isn't the best way to try to correct an error, this won't
automatically
* fail when the statement handle invalidates.
*/
/* XXX Actually, it might, if we're using a non-pooled connection.
Possible race here. XXX */

Only odbc_obj_connect and odbc_obj_disconnect lock obj->lock. So any other
user of the odbc_obj (func_odbc, realtime_odbc) can use it while it's being
deallocated. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-11 05:50 wdoekes        Note Added: 0121691                          
======================================================================