JDK-5103671 : Different behaviors with -Xdebug between 1.3.1 and tiger-b64
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-09-17
  • Updated: 2004-09-23
  • Resolved: 2004-09-23
Related Reports
Relates :  
Description
A customer has found out the different behavior between 1.3.1 and Tiger-b64
related to handling files.

 
REPRODUCE :
  1)  unfold the attached test.zip
  2) go to the dir. where the above zip file was unfolded.
  3) Launch "java -Xdebug FileLeak app1" in Tiger-b64
  4) go to temp dir.
  5) Try to delete the apps.jar by explore
      ==> You can not delete the file.
  Then track the the above steps in 1.3.1_11.
     ==> You CAN delete the apps.jar file at the step5.



PROGRAM FLOW:
  The test program, FileLeak works as follows.
  1) Load the class specified in arg. of FileLeeak from temp\apps.jar.
  2) Execute the loaded class.
  3) Clear all the references
  4) Invoke SystemGC
  5) Goto Sleep


PROBLEM :
  The type information stored in
    PlaceholderEntry*@SystemDictionary::_placeholder_bucketsmn
   (systemDictionary.cpp)  has never been deleted even though all the 
   reference are cleared.

   As a result, when users try to delete the file which type information are 
   stored they can not delete because of file busy.
  

MORE INFORMATION:
   - Program flow in JVM
        resolve_or_null() (in systemDictionary.cpp ) calls
        resolve_array_class_or_null(), when target class is array type.

       In resolve_array_class_or_null(),
          1) resolve_instance_class_or_null(j is called
             when the name of class is stored.
          2) record_primitive_array_loading() is called
             when the type is stored.

       Both in above 1) and 2), class name and type are stored in   
       placeholder_bbucket[] by add_placeholder() respectively.

       In the case 1), the stored class name is deleted from placeholder_bucket
       by remove_placeholder() in update_dictionary().
       However, in the case 2),  remove_placeholder() does not seem called.
       So, data can not be released and users can not delete the jar file.
         
   - JRE/JDK versions
        - 1.3.1_0X  : apps.jar file can be deleted
        - 1.4.2_0X  : apps.jar file can NOT be deleted
        - Tigerb64 :  apps.jar file can NOT be deleted

NOTE:
  Please try to launch
     "java -Xdebug FileLeak app2"
  in Tiger-b64.  You can delete apps.jar.
  Please check the diff. between app1.java and app2.java under temp dir.

Comments
EVALUATION This problem is related to the bug id 4979680. So closing this as duplicate of the above bug. But in general there is no guarantee when the class get unloaded and be able to delete a jar file. So when you want to delete a jar file which is used by java app it is always adviced to exit the java app and delete it. I think deletetion of a *jar file in the middle of java app running is not a wise idea. Name: dd4877 Date: 09/23/2004 daniel.daugherty@Sun 2004-09-23 The following bug was fixed in Tiger: 4979680 2/2 objects being kept alive in perm gen and old gen because it affected all Java invocations and not just -Xdebug invocations. The following bug: 5093520 4/2 objects being kept alive in perm gen and old gen when debugger attached was filed to track the remaining work and is still open. This bug should have been closed as a duplicate of the open bug and not the integrated bug. ======================================================================
24-09-2004