It is possible that a thread could deadlock waiting on a mutex
it already owns due to a c compiler issue where existing code to
unlock the mutex in the case of a caught signal exception was
optimized out of the generated assembly code. Due to this, it
leaves a mutex locked, when just a SQL code would be returned to
the client. Then the next time that mutex needs to be locked,
there are issues because it was not released properly.
Example onstat -g lmx output:
IBM Informix Dynamic Server Version 12.10.UC5W1 -- On-Line -- Up
2 days 02:55:11 -- 363640 Kbytes
Locked mutexes:
242064 55e22398 scbthd 15371 0 15371
169427
The 2 mutexes that are vulnerable in this sysmaster query case
are the above mentioned "scbthd" mutex along with the "sqtcb"
The query being run against sysmaster that encountered the
problem was this:
Current SQL statement (4) :
select distinct cbl_estcost, cbl_sessionid, cbl_stmt, username
from
sysconblock , syssdblock , syssessions where cbl_stmt != ''
and
syssessions.sid = sysconblock.cbl_sessionid and
syssessions.sid =
syssdblock.sdb_sessionid
and the stack trace for the hung thread:
(oninit)mt_lock_wait
(oninit)mt_lock
(oninit)mt_nxtscb
(oninit)prstmtdb
(oninit)pstread
(oninit)pst_rsread
(oninit)rsread
(oninit)fmread
(oninit)getsinglerow
(oninit)readidx_new
(oninit)gettupl
(oninit)scan_next
(oninit)join_next
(oninit)sort_open
(oninit)prepselect
(oninit)open_cursor
(oninit)sql_open
(oninit)sq_open
(oninit)sqmain |
