JDK-6321722 : On windows, sometimes jar file cannot be deleted even when there is no reference to it
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2005-09-08
  • Updated: 2010-05-11
  • Resolved: 2005-11-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6 b59Fixed
Related Reports
Relates :  
Relates :  
Relates :  
On windows, when executing the attached testcase, the deletion of the particular jar 
(when prompted to do so) would succeed for pre-mustang releases (and some early 
mustang builds) and fail when using the more recent mustang builds (say b50).

This is observed when verifying the fix for a JCE bug (5098318) "Cached Jar file 
should be released on appl. exit even that is opended by Cipher" against various 
J2SE releases. After turning the caching off in JCE, the testcase for 5098318 
passes for 1.4.2, 1.5.0 releases, and early mustang builds (say b04), and failed 
for more recent mustang builds.

The attached testcase is based on the testcase for 5098318 but it stripped off the
dependency on JCE. 
Lastly, one interesting observation from Brad Wetmore is that the jar deletion
often succeeded when class Hello is unloaded (by setting -XX:+TraceClassUnloading) 
and failed otherwise.
A few more comments.

Here's one of the problems which made this difficult to analyze, but please note,
Valerie has isolated JCE from the problem, so it's not JCE.

This could be a ZIP/Jar file issue, but I'm not convinced because the test
passed with "n" of jar entries reads, but failed with "n+1".  This seems to 
be pointing more to GC.

In the JCE jar verification, a class file is verified by reading its contents 
and comparing signed hash values.  For a successful verification,
we take every class file in the jar and make sure every 
signature is valid.  If I stopped verification step after 8 jar elements,
the war class was unloaded and the jar file could be deleted.  However,
if I stopped verification after 9 or more jar elements, the class was NOT unloaded
and the jar file could not be deleted.

I went through the hprof data, and could find no references to the Hello class
from the root set, and thus couldn't find any reason why this wasn't being 
unloaded.  I'm not an expert in this area by any means, so I may
have misread something.

This is concerning because there was an escalation filed against JCE for 1.4.2/1.5,
and will probably be the same problem under 1.6 if not fixed.  We have put
back the JCE change to not hold the reference, but if the GC isn't working right,
we may be back to another escalation.


EVALUATION Valerie reports: Both the modified (which I modified to remove the dependency on JCE) and the original (which uses JCE) testcase work as expected, i.e. fail on b58 and pass on b59. Guess we finally have this hard-to-trace bug nailed down and fixed. :)

EVALUATION This was fixed as a side effect of 6320351. JavaThread::_exception_oop was hanging onto a copy of the exception and never clearing. This was introduced by 5095053. Cleaning up the exception paths in 6320351 also added code to properly clear this field as a side effect. Since 6320351 wasn't an explicit fix of this bug I'm not marking this bug as a duplicate. I'm just marking it fixed in the same build.