[unixODBC-support] Deadlock

Michal Ramon mrdanieli at yahoo.com
Sun Dec 26 16:03:52 GMT 2004


Hello,
I hope I am posting to the right list...

Anyways, our C++ application, while using libodbc++
and unixODBC packages, seems to get stuck quite
frequently.

ps shows something like:
odbc   31084 23014  0 Dec24 ?        00:00:00    
postgres: sd sddb [local] UPDATE waiting
odbc   31490 23014  0 Dec24 ?        00:00:00    
postgres: sd sddb [local] idle in transaction

Now, using gdb for both threads, we have found the
following stacks:

#0  0x401ccca5 in sigsuspend () from /lib/libc.so.6
#1  0x40068c79 in pthread_setconcurrency () from
/lib/libpthread.so.0
#2  0x4006b069 in sem_destroy () from
/lib/libpthread.so.0
#3  0x40066e16 in pthread_mutex_lock () from
/lib/libpthread.so.0
#4  0x40315834 in mutex_entry (mutex=0x403376e4) at
__handles.c:296
#5  0x402f63b9 in SQLFreeStmt
(statement_handle=0x97d5158, option=1) at
SQLFreeStmt.c:146
#6  0x400d3397 in odbc::Statement::~Statement
(this=0xbf7fe624, __in_chrg=0) at statement.cpp:67
#7  0x400dab96 in
odbc::PreparedStatement::~PreparedStatement
(this=0x97b46e8, __in_chrg=3) at
/usr/include/g++-3/std/bastring.h:210
...

AND

#0  0x4028e4c2 in recv () from /lib/libc.so.6
#1  0x4006b964 in recv () from /lib/libpthread.so.0
#2  0x40365c78 in SOCK_get_next_byte (self=0x85fa2b0)
at socket.c:370
#3  0x4034e762 in CC_send_query (self=<incomplete
type>, 
    query=0x996ce36 "UPDATE "..., qi=0x0) at
connection.c:1024
#4  0x4036700f in SC_execute (self=0x996cd70) at
statement.c:860
#5  0x40357409 in PG_SQLExecute (hstmt=0x996cd70) at
execute.c:324
#6  0x403570a4 in PG_SQLExecDirect (hstmt=0x996cd70, 
    szSqlStr=0x96e96c8 "UPDATE "..., cbSqlStr=241) at
execute.c:196
#7  0x403570e4 in SQLExecDirect (hstmt=0x996cd70, 
    szSqlStr=0x96e96c8 "UPDATE "..., cbSqlStr=241) at
execute.c:205
#8  0x402f424e in SQLExecDirect
(statement_handle=0x97e8358, 
    statement_text=0x96e96c8 "UPDATE "...,
text_length=241) at SQLExecDirect.c:414
#9  0x400d93b6 in odbc::Statement::execute
(this=0x972b6a0, sql=@0xbffeb630) at
/usr/include/g++-3/std/bastring.h:172
#10 0x400d9b95 in odbc::Statement::executeUpdate
(this=0x972b6a0, sql=@0xbffeb630) at statement.cpp:724
...

It seems to me that first thread (working in a
transaction) is trying to terminate the (successful)
statement while it gets stuck in SQLFreeStmt -->
thread_protect --> mutex_entry( &mutex_env ) while the
other (also in a DIFFERENT
connection+statement+transaction) is waiting for this
termination to complete (both manipulating same table
of course).

Obviously, I do not understand the flow, but why does
it try to lock on env level (TS_LEVEL3)? What is going
on here?

Environment:
Red Hat Linux 2.1AS.
unixodbc-2.2.10 (configured with: --with-gnu-ld=yes
--enable-threads=yes --enable-gui=yes
--enable-static=yes --enable-drivers)
libodbc++-0.2.3 (configured also for threads and for
odbc version 0x0250)

Thanks a lot.

Ramon




		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 



More information about the unixODBC-support mailing list