JDK-6225497 : regression: plugin stalls
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u1
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2005-02-04
  • Updated: 2010-08-03
  • Resolved: 2005-03-25
Related Reports
Relates :  
Description
Trying to open video stream contens at following web site,
http://jp.sun.com/products/software/solaris/10/devmeeting/
(Click on one of any 3 display like icons)
the Java plug-in stalls after some time. The time untill it stalls seems to depend on machine configurations. 10 sec, 10 min, or on some boxes don't even start at all.

This happens when used Tiger and later. NOT REPRODUCIBLE with 1.4.2_xx.

Configurations tested:
Solaris10, Mozilla 1.7, jdk1.5.0_01
Solaris10, Mozilla 1.7, jdk1.4.2_06
WindowsXP, Mozilla 1.7.5 & FireFox 1.0, jdk1.5.0

Not sure but the phenomenon looks something related to
5072892 multiple applets making liveconnect calls hang browser

Attached plugin.log is a java console log.
###@###.### 2005-2-04 08:55:51 GMT


###@###.### 2005-2-04 21:51:04 GMT

Attaching following 2 files illustrates the problem.
 - devmtgstacktrace.txt (includes stack trace)
 - plugin150_01.trace (includes properties dump)

###@###.### 2005-2-07 08:43:55 GMT

Comments
EVALUATION All 3 video applet streams loaded just fine repeatedly for me without any hang or stall. Each video stream involves a series of applets loaded to synchroneously display on the browser the presentation slides, one after another at the same time with the speaker who switches his slides as seen in the video showed at the side. Synchroneous slides switching is done using Javascript calling to Java. Once a while during the presentation, I do notice liveconnect trace report url permission settings limitation on some of the slides (see sample below). "liveconnect: the url of the applet is http://211.14.7.43 and the permission is = false" And as the result, some of the presentation slides fail to get display (compared to what seen in the video). This, however, is permission setting on the server, and failure to load one slide does not prevent subsequent slides to not get displayed. The configuration I tested are: Solaris10, Mozilla 1.7, jdk1.5.0_01 and jdk1.5.0_03 B3 Solaris10, Mozilla 1.7, jdk1.4.2_06 WindowsXP, Mozilla 1.7.3 & FireFox 1.0, jdk1.5.0 and 1.5.0_03 B3 I also attached trace file that show all three applets stream loaded and shutdown just fine. If you ran into the problem again, please turn on plugin trace and collect trace file and send to us. ###@###.### 2005-2-04 21:51:04 GMT ================================================================= Okay, I reviewed the trace file you attached. The hang seems to happen for you during the url access permission problem for some applets in the series. The video applet streams were written with signed JS script where UniversalBrowserRead and UniversalJavaPermission enabled. Access permission was denied on several applets. However, it never hang on me: the slide with access permission won't get loaded, but the next slides still go on. Since problem also appeared for you on WinXP, when the hang happened, please send the following info for us: - stack trace when problem occur. To get stack trace, add "-verbose" to jvm's args before launch applet; when problem occurs, hit <ctrl-break>, copy the screen dump and send to us. - deploy's system properties. To get this, open java console, hit <s> to dump the system properties, copy and send us the contents. ###@###.### 2005-2-04 22:18:23 GMT ================================================================ The stack trace you provided indicates that the hang has nothing to do with Java Plugin. I.e, no Java Plugin code involved in this lock-up During this lock up, the only thing that was still active is: "AWT-Windows" daemon prio=7 tid=0x04c3f970 nid=0x574 runnable [0x08f5f000..0x08f 5fae8] at sun.awt.windows.WToolkit.eventLoop(Native Method) Yet, it seems that both: "Audio Player" daemon prio=10 tid=0x04c55478 nid=0x370 waiting on condition [0x0 ac6f000..0x0ac6fae8] and "Image Animator 0" daemon prio=4 tid=0x04d97580 nid=0x770 waiting on condition [ 0x0a5ef000..0x0a5efae8] are sleeping, and everything is awaiting. As of this point, I would suggest you to try with latest build of 1.5.0_02, 1.5.0_03, and 1.6.0 to see if they make a difference. As if I were to try them, I wouldn't be able to tell the difference since I could not duplicate the problem here with 1.5.0_01 in the first place. If problem fixed, please rescind to use latest update bundle, else, this bug will need to be reassigned as it doesn't involve plugin code. ###@###.### 2005-2-12 00:48:20 GMT Closed. Bug has been in "incomplete" (waiting for more info from submitter) since 2/12/05. ###@###.### 2005-03-25 22:30:25 GMT
04-02-2005