United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7123063 progress bar still can be seen after app window is shown.
7123063 : progress bar still can be seen after app window is shown.

Details
Type:
Bug
Submit Date:
2011-12-20
Status:
Resolved
Updated Date:
2012-10-01
Project Name:
JDK
Resolved Date:
2012-06-13
Component:
deploy
OS:
generic,windows_xp,windows
Sub-Component:
webstart
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7,8
Fixed Versions:
8

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
Env: 32bit winxp, 7u4 b04 and 8 b17

Steps to reproduce:
1) http://nicole1.us.oracle.com:8080/JavawsMustangIntegTest/custom_progress/custom_progress_signed.jnlp
2) if the progress bar doesn't disappear after app window is shown, bug is reproduced.
A screen shot is attached.

Found the issue in pit bundle http://rehudson.us.oracle.com:8080/hudson/job/jdk8_deploy-1-prebuild/ws/bundles/windows-i586/b255-2011-12-09_92/
but cross check with the current promotion 8 or 7u4, so it's not regression against this pit

                                    

Comments
EVALUATION

Do not use weak references. Explicitly reset references to null after applet is shutdown.
                                     
2012-06-11
EVALUATION

I believe this is regression introduced in 6709152.

What happens is that 
   1) custom progress is getting instantiated and start getting events through the 
        "adapter preloader"
   2) preloaderdelegate only keep weak reference to adapter preloader and nobody else
   3) GC collects "adpater preloader" object breaking link between preloader delegate and custom progress
   4) events are getting queued at preloaderdelegate but custom progress never receives them and stucks on the screen

It seem that solution will be to not use weak reference in preloader delegate as from the mail thread for 6709152 we seem to explicitly 
reset preloaderdelegate on applet reload (unfortunatelly CR itself does not have any details on why we made this change). 

Reassigning to author of 6709152 to ensure we will not reintroduce memory leak.
                                     
2012-01-13



Hardware and Software, Engineered to Work Together