Calling createStatement() after the connection is closed results in VM Death

Name: rmT116609 Date: 09/22/2004


FULL PRODUCT VERSION :
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)

java version "1.5.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63)
Java HotSpot(TM) Client VM (build 1.5.0-rc-b63, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
After upgrading my system to MDAC version 2.8, I found that my application crashed with a VM Death. This is caused by calling createStatement() on a connection that has been closed. I was previously using MDAC version 2.6 and did not encounter a VM Death with the exact same code.

It is also important to know that a "service pack" release of MDAC 2.8 is including in Microsofts Windows XP Service Pack 2. This release of MDAC also causes the VM Death.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the included program. The only necessity is to have an MDB (MS Access Database File) available, although it's contents are never used by this test application.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect that the createStatement() method will either succeed (and a later executeQuery() or executeUpdate() would throw an exception) or the createStatement() method will throw an exception if the connection is already closed.
ACTUAL -
A VM Death occurs.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x77F8206B
Function=RtlEnterCriticalSection+0xB
Library=C:\WINNT\system32\ntdll.dll

Current Java thread:
at sun.jdbc.odbc.JdbcOdbc.allocStmt(Native Method)
at sun.jdbc.odbc.JdbcOdbc.SQLAllocStmt(JdbcOdbc.java:171)
at sun.jdbc.odbc.JdbcOdbcConnection.createStatement(JdbcOdbcConnection.java:413)
at sun.jdbc.odbc.JdbcOdbcConnection.createStatement(JdbcOdbcConnection.java:396)
at MDACTest.main(MDACTest.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.intellij.rt.execution.application.AppMain.main(Unknown Source)

Dynamic libraries:
0x00400000 - 0x0040B000 C:\WEBCTRL_3.0\java\windows\bin\java.exe
0x77F80000 - 0x77FFD000 C:\WINNT\system32\ntdll.dll
0x7C2D0000 - 0x7C332000 C:\WINNT\system32\ADVAPI32.dll
0x7C570000 - 0x7C628000 C:\WINNT\system32\KERNEL32.DLL
0x77D30000 - 0x77DA1000 C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78045000 C:\WINNT\system32\MSVCRT.dll
0x08000000 - 0x08139000 C:\WEBCTRL_3.0\java\windows\jre\bin\client\jvm.dll
0x77E10000 - 0x77E75000 C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7E000 C:\WINNT\system32\GDI32.DLL
0x77570000 - 0x775A0000 C:\WINNT\system32\WINMM.dll
0x10000000 - 0x10007000 C:\WEBCTRL_3.0\java\windows\jre\bin\hpi.dll
0x007C0000 - 0x007CE000 C:\WEBCTRL_3.0\java\windows\jre\bin\verify.dll
0x007D0000 - 0x007E9000 C:\WEBCTRL_3.0\java\windows\jre\bin\java.dll
0x007F0000 - 0x007FD000 C:\WEBCTRL_3.0\java\windows\jre\bin\zip.dll
0x18870000 - 0x18877000 C:\IntelliJ-IDEA-4.0\bin\breakgen.dll
0x189D0000 - 0x189DF000 C:\WEBCTRL_3.0\java\windows\jre\bin\net.dll
0x75030000 - 0x75044000 C:\WINNT\system32\WS2_32.dll
0x75020000 - 0x75028000 C:\WINNT\system32\WS2HELP.DLL
0x189E0000 - 0x189EC000 C:\WEBCTRL_3.0\java\windows\jre\bin\JdbcOdbc.dll
0x1F7A0000 - 0x1F7D6000 C:\WINNT\system32\ODBC32.dll
0x71710000 - 0x71794000 C:\WINNT\system32\COMCTL32.dll
0x782F0000 - 0x78535000 C:\WINNT\system32\SHELL32.dll
0x70A70000 - 0x70AD4000 C:\WINNT\system32\SHLWAPI.dll
0x76B30000 - 0x76B6E000 C:\WINNT\system32\comdlg32.dll
0x1F840000 - 0x1F857000 C:\WINNT\system32\odbcint.dll
0x77A50000 - 0x77B3F000 C:\WINNT\system32\ole32.dll
0x1F7F0000 - 0x1F80A000 C:\WINNT\system32\odbccp32.dll
0x77820000 - 0x77827000 C:\WINNT\system32\VERSION.dll
0x759B0000 - 0x759B6000 C:\WINNT\system32\LZ32.DLL
0x74FD0000 - 0x74FEE000 C:\WINNT\system32\msafd.dll
0x75010000 - 0x75017000 C:\WINNT\System32\wshtcpip.dll
0x77920000 - 0x77943000 C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000 C:\WINNT\system32\DBGHELP.dll
0x690A0000 - 0x690AB000 C:\WINNT\system32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation total 576K, used 421K [0x10010000, 0x100b0000, 0x104f0000)
  eden space 512K, 69% used [0x10010000, 0x10069648, 0x10090000)
  from space 64K, 100% used [0x100a0000, 0x100b0000, 0x100b0000)
  to space 64K, 0% used [0x10090000, 0x10090000, 0x100a0000)
 tenured generation total 1408K, used 102K [0x104f0000, 0x10650000, 0x14010000)
   the space 1408K, 7% used [0x104f0000, 0x10509bd8, 0x10509c00, 0x10650000)
 compacting perm gen total 4096K, used 1770K [0x14010000, 0x14410000, 0x18010000)
   the space 4096K, 43% used [0x14010000, 0x141ca940, 0x141caa00, 0x14410000)

Local Time = Fri Sep 10 11:37:29 2004
Elapsed Time = 0
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode)
#
# An error report file has been saved as hs_err_pid1636.log.
# Please refer to the file for further information.
#

With 5.0 RC:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x77f8206b, pid=1660, tid=1588
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-rc-b63 mixed mode, sharing)
# Problematic frame:
# C [ntdll.dll+0x206b]
#
# An error report file with more information is saved as hs_err_pid1660.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.sql.*;
import java.io.File;

public class MDACTest
{
   public static void main(String[] args) throws Exception
   {
      if (args.length < 1)
      {
         System.out.println("The one and only argument must be a path to an MDB (MS Access Database)");
         return;
      }

      File mdb = new File(args[0]);
      if (!mdb.exists())
      {
         System.out.println("The specified file (" + mdb.getAbsolutePath() + ") does not exist.");
         return;
      }

      Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
      Connection conn = DriverManager.getConnection("jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ="+mdb.getAbsolutePath());
      conn.close();

      // This line causes the VM death
      conn.createStatement();
   }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Don't use a connection after it is closed! I have an issue with this workaround, however (funny as that may seem). What I have is a unit test where I wish to test the handling of SQL Exceptions. To make this happen, my unit test closes the database connection and then calls the method under test. Because of this bug, I now have to stop running this unit test.

If anyone can provide a better solution to "forcing" an exception to occur during my unit test, I would appreciate it.
(Incident Review ID: 305608)
======================================================================