DB2CLI Crash in multithreading

[alinehp]

Hi

I have an access violation in DB2SYS.dll at each ending of my
application.
This is a multithreaded application. Threads are created and managed by
Tomcat. One thread connects to DB2 base through ODBC and a C++ DLL.
Another thread ends the application and disconnects. The disconnection
is not even traced by DB2CLI.
I add all traces I could gather.

I would thank any help on this issue.

Regards,

Aline

================================================== =====
Crash Traces :
-------------------

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6c9197b6, pid=3772,
tid=2084
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode)
# Problematic frame:
# C [DB2SYS.dll+0x397b6]
#

--------------- T H R E A D ---------------

Current thread (0x008a4e90): VMThread [id=2084]

siginfo: ExceptionCode=0xc0000005, reading address 0x31c88860

Registers:
EAX=0x00000000, EBX=0x0000001e, ECX=0x31c88850, EDX=0x00000014
ESP=0x2f6ff764, EBP=0x2f6ff780, ESI=0x31c88850, EDI=0x00000001
EIP=0x6c9197b6, EFLAGS=0x00010212

Top of Stack: (sp=0x2f6ff764)
0x2f6ff764: 314bf19a 31879348 31879348 00000000
0x2f6ff774: 314d0b72 0000001e 31c88850 2f6ff79c
0x2f6ff784: 6c1659bd 31c88850 00000001 00000000
0x2f6ff794: 00000000 0000001d 2f6ff7e8 6c1ae13a
0x2f6ff7a4: 0001001e 2f6ff7c0 2f6ff7c4 2f6ff7cc
0x2f6ff7b4: 2f6ff7ec 314ae168 31878690 00000000
0x2f6ff7c4: 00000000 31740000 001932f0 00000000
0x2f6ff7d4: 2f6ffad8 00000000 00000001 00000000

Instructions: (pc=0x6c9197b6)
0x6c9197a6: 89 75 fc 89 5d f8 8b 75 08 c7 45 f0 00 00 00 00
0x6c9197b6: 0f b6 46 10 85 c0 75 29 0f b6 46 01 a8 01 0f 85
Stack: [0x2f6c0000,0x2f700000), sp=0x2f6ff764, free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [DB2SYS.dll+0x397b6]
C [DB2APP.dll+0x1559bd]
C [DB2APP.dll+0x19e13a]
C [aamapi50.dll+0x40739d]
....

VM_Operation (0x3253f92c): exit, mode: safepoint, requested by thread
0x2fd64960

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x2fd64960 JavaThread "SIGINT handler" daemon [_thread_blocked,
id=3996]
0x2fc1da28 JavaThread "http-8080-Processor25" daemon
[_thread_blocked, id=3404]
....

Other Threads:
=>0x008a4e90 VMThread [id=2084]

VM state:at safepoint (shutting down)

VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x000379a0/0x0000071c] Threads_lock - owner thread: 0x008a4e90

--------------- S Y S T E M ---------------

OS: Windows XP Build 2600 Service Pack 2

CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 2096028k(1073152k free), swap
4034168k(3048464k free)

vm_info: Java HotSpot(TM) Client VM (1.5.0_04-b05) for windows-x86,
built on Jun 3 2005 02:10:41 by "java_re" with MS VC++ 6.0

================================================== =====
DB2CLI traces :
---------------------

[ Process: 3772, Thread: 3404 ]
[ Date & Time: 20.06.2006 18:36:06.897001 ]
[ Product: QDB2/NT DB2 v8.1.12.99 ]
[ Level Identifier: 03060106 ]
[ CLI Driver Version: 08.01.0000 ]
[ Informational Tokens: "DB2 v8.1.12.99","s060429","WR21368","Fixpack
12" ]

SQLAllocEnv( phEnv=&31898c5e )
---> Time elapsed - 0 seconds

SQLAllocEnv( phEnv=0:1 )
<--- SQL_SUCCESS Time elapsed - +6.400000E-003 seconds

SQLAllocConnect( hEnv=0:1, phDbc=&31898840 )
---> Time elapsed - +3.647000E-003 seconds

SQLAllocConnect( phDbc=0:1 )
<--- SQL_SUCCESS Time elapsed - +7.343000E-003 seconds

SQLSetConnectOption( hDbc=0:1, fOption=SQL_ATTR_AUTOCOMMIT, vParam=1 )
---> Time elapsed - +3.486000E-003 seconds

SQLSetConnectOption( )
<--- SQL_SUCCESS Time elapsed - +7.911000E-003 seconds

SQLConnect( hDbc=0:1, szDSN="acdb2", cbDSN=5, szUID="db2admin",
cbUID=8, szAuthStr="******", cbAuthStr=6 )
---> Time elapsed - +3.507000E-003 seconds
( DBMS NAME="DB2/NT", Version="08.02.0005", Fixpack="0x23060106" )
( Application Codepage=1252, Database Codepage=1252, Char Send/Recv
Codepage=1252, Graphic Send/Recv Codepage=1200 )

SQLConnect( )
<--- SQL_SUCCESS Time elapsed - +3,260550E-001 seconds
( DSN=""ACDB2"" )
( UID=""db2admin"" )
( PWD="******" )
( KEEPSTATEMENT="30" )
( PATCH1="1024" )
( TEMPDIR="C:\DOCUME~1\AGUILL~1\LOCALS~1\Temp\db2tem p\" )
( APPENDAPINAME="1" )

SQLGetInfo( hDbc=0:1, fInfoType=SQL_DRIVER_ODBC_VER,
rgbInfoValue=&3189cdd0, cbInfoValueMax=256, pcbInfoValue=&30e1ece4 )
---> Time elapsed - +3,452300E-002 seconds

SQLGetInfo( rgbInfoValue="03.51", pcbInfoValue=5 )
<--- SQL_SUCCESS Time elapsed - +1,550500E-002 seconds
[ Process: 3772, Thread: 2084 ]
[ Date & Time: 20.06.2006 18:46:09.839002 ]
[ Product: QDB2/NT DB2 v8.1.12.99 ]
[ Level Identifier: 03060106 ]
[ CLI Driver Version: 08.01.0000 ]
[ Informational Tokens: "DB2 v8.1.12.99","s060429","WR21368","Fixpack
12" ]

================================================== =====
Application Traces :
---------------------------

2006/06/20 18:36:6.913 1 128 [Thrd#:3404]SQLAllocEnv
2006/06/20 18:36:6.929 1 128 [Thrd#:3404]SQLAllocConnect
2006/06/20 18:36:6.929 1 128 [Thrd#:3404]SQLSetConnectOption
2006/06/20 18:36:7.287 1 128 [Thrd#:3404]SQLConnect
2006/06/20 18:36:7.319 1 128 [Thrd#:3404]SQLGetInfo
2006/06/20 18:36:7.287 1 128 [Thrd#:2084]SQLDisconnect

[mike]

Not sure if this will help, but I ensure the thread that
does the SQLConnect is the same as the one that
does the SQLDisconnect, and does an SQLEndTran
before the disconnect, and the FreeHandle after the
disconnect.

[alinehp]

mike a écrit :

I ensure the thread that does the SQLConnect is the same as the one that
does the SQLDisconnect

I would like to... but Tomcat manages the threads, not the dll which
makes the connections/disconnections... and serializing all connections
on dll side would have a major impact on the performances of the
application.

However, thanks for the advice.

Aline

[mike]

I'm puzzled why Tomcat has not done an SQLEndTran
although not sure if that is what is upsetting db2sys.dll.
The CLI trace does not help me see a possible cause, so
I wonder if you could experiment with db2trc to see if
the SQLDisconnect gets as far as the server and
what the server is doing in response. You might
need to rtfm carefully for the tracing, choosing when
to start and stop the trace etc.

[alinehp]

mike a écrit :

I'm puzzled why Tomcat has not done an SQLEndTran
although not sure if that is what is upsetting db2sys.dll.
In fact, enven an SQLFreeStmt crashes... so the pb can not be solved
with an SQLEndTran.
The CLI trace does not help me see a possible cause, so
I wonder if you could experiment with db2trc to see if
the SQLDisconnect gets as far as the server and
what the server is doing in response. You might
need to rtfm carefully for the tracing, choosing when
to start and stop the trace etc.

Thanks for this information. I used this db2trc and analysed the
traces. I found the origin of the problem.
We use a DLL in our application for database queries. This DLL loads
DB2CLI.DLL. At the end of the application, all DLLs receive a
DLL_PROCESS_DETACH, but DB2CLI.DLL receives this message before our own
DLL. So, when our own DLL receives the DLL_PROCESS_DETACH and tries to
close all open connections, they are already closed, and handles are
already freed... and SQLFreeStmt or SQLDisconnect calls crash. They
should return an SQL_INVALID_HANDLE instead, as does an SQLAllocConnect
(I tried one).

I opened a problem report to IBM. Meanwhile, this information can be
useful for other developers... :)