United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6510204 : Java applets load repeatedly hangs Firefox

Details
Type:
Bug
Submit Date:
2007-01-05
Status:
Closed
Updated Date:
2010-12-06
Project Name:
JDK
Resolved Date:
2008-01-28
Component:
deploy
OS:
solaris_10,solaris_nevada
Sub-Component:
plugin
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u11,6
Fixed Versions:
6u10 (b02)

Related Reports
Backport:

Sub Tasks

Description
Test case:
http://leadbelly.lanl.gov/lanl_ep_data/cgi-bin/ep_plot_choose_3.cgi/19980311/LANL_GEO_LoE_00-24/1/2

Steps to reproduce:
Keep clicking the left and right button on the up-right corner, the browser will hang on Solaris snv54, sometimes crash.

This bug is related to the mozilla community bug: https://bugzilla.mozilla.org/show_bug.cgi?id=323175. The reporter said that it can also be reproduced on Windows and Linux.

After some investigation, the hang is caused by an infinite loop in the code block of JavaVM5.cpp:
"
  while (spontPipeClean && (pluginInstance->GetStatus()) < APPLET_START) {
    /* Wait for the applet notify us that APPLET IS STARTED
       while waiting, we need to poll the worker queue since
       there maybe a request from java side such as cookie/proxy
       request.
     */
    ProcessWorkQueue();
  }
"

And also the error message in the Java console:
"
Exception in thread "Thread-10" java.lang.NullPointerException
    at sun.plugin.util.AnimationPanel.createTranslucentImage(AnimationPanel.java:232)
    at sun.plugin.util.AnimationPanel.createGradientShapeImage(AnimationPanel.java:244)
    at sun.plugin.util.AnimationPanel.initBackground(AnimationPanel.java:320)
    at sun.plugin.util.AnimationPanel.preloadResources(AnimationPanel.java:509)
    at sun.plugin.util.AnimationPanel.doPaint(AnimationPanel.java:565)
    at sun.plugin.util.AnimationPanel.run(AnimationPanel.java:1061)
    at java.lang.Thread.run(Thread.java:619)
"

The return value of pluginInstance->GetStatus() is always 0 which is APPLET_DISPOSE. That's to say, the applet isn't started at all.

And also the stack trace when Firefox hangs:
=>[1] __pollsys(0x80450b8, 0x1, 0x8045088, 0x0), at 0xd1dc88f5 
  [2] _pollsys(0x80450b8, 0x1, 0x8045088, 0x0), at 0xd1dbbdf6 
  [3] _poll(0x80450b8, 0x1, 0x0), at 0xd1d7f7b2 
  [4] JavaVM5::ProcessWorkQueue(0x8d5bd80), at 0xcb4b37e4 
  [5] JavaVM5::GetJavaObjectForInstance(0x8d5bd80, 0x1), at 0xcb4b4623 
  [6] JavaPluginFactory5::GetJavaObjectForInstance(0x8d5a7a0, 0x1), at 0xcb4afdef 
  [7] JavaPluginInstance5::GetJavaObject(0x8d42578, 0x80451b8), at 0xcb4b1ed9 
  [8] CNSAdapter_JavaPlugin::GetJavaObject(0x8c848a0, 0x80451b8), at 0xcb50fc02 
  [9] nsHTMLAppletElementSH::GetPluginJSObject(0x8c302d0, 0x8c2ecb8, 0x8b0df68, 0x8c848a0, 0x8045220, 0x8045224), at 0xcd73d5a2 
  [10] nsHTMLExternalObjSH::PostCreate(0x8c302d0, 0x8c31038, 0x8c2ecb8, 0x8b0df68), at 0xcd73ccde 
  [11] XPCWrappedNative::GetNewOrUsed(0x80453e8, 0x8d3ca48, 0x8c43100, 0x819d640, 0x0, 0x80453a8), at 0xce3ad97e 
  [12] XPCConvert::NativeInterface2JSObject(0x80453e8, 0x80454bc, 0x8d3ca48, 0xcda5f968, 0x8b98728, 0x0, 0x0, 0x8045470), at 0xce396231 
  [13] nsXPConnect::WrapNative(0x81482d0, 0x8c2ecb8, 0x8b98728, 0x8d3ca48, 0xcda5f968, 0x80454bc), at 0xce384478 
  [14] nsDOMClassInfo::WrapNative(0x8c2ecb8, 0x8b97d60, 0x8d3ca48, 0xcda5f968, 0x8045718, 0x8045508), at 0xcd726a85 
  [15] nsHTMLDocumentSH::GetProperty(0x8535300, 0x8c029b8, 0x8c2ecb8, 0x8b97d60, 0x8bca09c, 0x8045718, 0x8045568), at 0xcd73a75e 
  [16] XPC_WN_Helper_GetProperty(0x8c2ecb8, 0x8b97d60, 0x8bca09c, 0x8045718), at 0xce3b7513 
  [17] js_GetProperty(0x8c2ecb8, 0x8b97d60, 0x8c35188, 0x8045718), at 0xd1944157 
  [18] js_Interpret(0x8c2ecb8, 0x8cc923b, 0x8045838), at 0xd192ca56 
  [19] js_Invoke(0x8c2ecb8, 0x1, 0x2), at 0xd192635c 
  [20] nsXPCWrappedJSClass::CallMethod(0x8631cd0, 0x8c9d330, 0x3, 0x835ee78, 0x8045b00), at 0xce3abf11 
  [21] nsXPCWrappedJS::CallMethod(0x8c9d330, 0x3, 0x835ee78, 0x8045b00), at 0xce3a613f 
  [22] PrepareAndDispatch(0x8c9d330, 0x3, 0x8045be0), at 0xd1cb4cc0 
  [23] nsXPTCStubBase::Stub3(0x8c9d330, 0x8bbcee0), at 0xd1cb4dc0 
  [24] nsEventListenerManager::HandleEventSubType(0x8c912c8, 0x8c238b0, 0x8c9d330, 0x8bbcee0, 0x8be8a50, 0x1, 0x4), at 0xcd593f08 
  [25] nsEventListenerManager::HandleEvent(0x8c912c8, 0x8c36670, 0x8046668, 0x80461c0, 0x8be8a50, 0x4, 0x8046490), at 0xcd5943c3 
  [26] nsGenericElement::HandleDOMEvent(0x8cb4500, 0x8c36670, 0x8046668, 0x80461c0, 0x4, 0x8046490), at 0xcd54c1c8 
  [27] nsGenericElement::HandleDOMEvent(0x8cb4578, 0x8c36670, 0x8046668, 0x80461c0, 0x4, 0x8046490), at 0xcd54c066 
  [28] nsGenericElement::HandleDOMEvent(0x8c28648, 0x8c36670, 0x8046668, 0x80461c0, 0x7, 0x8046490), at 0xcd54c066 
  [29] nsHTMLImageElement::HandleDOMEvent(0x8c28648, 0x8c36670, 0x8046668, 0x0, 0x1, 0x8046490), at 0xcd5fb5b1 
  [30] PresShell::HandleEventInternal(0x8c35ca0, 0x8046668, 0x8d5d090, 0x1, 0x8046490), at 0xcd338b3b 
  [31] PresShell::HandleEvent(0x8c35ca0, 0x8d5d090, 0x8046668, 0x8046490, 0x0, 0x8046494), at 0xcd3386ef 
  [32] nsViewManager::HandleEvent(0x8c370f8, 0x8c72410, 0x8046668, 0x0), at 0xcd6e76b2 
  [33] nsViewManager::DispatchEvent(0x8c370f8, 0x8046668, 0x80465bc), at 0xcd6e68da 
  [34] HandleEvent(0x8046668), at 0xcd6dc946 
  [35] nsCommonWidget::DispatchEvent(0x8c72938, 0x8046668, 0x80466c0), at 0xce2c539e 
  [36] nsWindow::OnMotionNotifyEvent(0x8c72938, 0x8321138, 0x83a7140), at 0xce2ba110 
  [37] motion_notify_event_cb(0x8321138, 0x83a7140, 0x0), at 0xce2bf851 
  [38] _gtk_marshal_BOOLEAN__BOXED(0x841f0e0, 0x80467b0, 0x2, 0x804686c, 0x80467cc, 0x0), at 0xd16bcca8 
  [39] g_closure_invoke(0x841f0e0, 0x80467b0, 0x2, 0x804686c, 0x80467cc), at 0xd13be073 
  [40] signal_emit_unlocked_R(0x815e688, 0x0, 0x8321138, 0x80469ec, 0x804686c), at 0xd13d1cce 
  [41] g_signal_emit_valist(0x8321138, 0x1f, 0x0, 0x8046ae0), at 0xd13d0d7e 
  [42] g_signal_emit(0x8321138, 0x1f, 0x0, 0x83a7140, 0x8046b04), at 0xd13d1175 
  [43] gtk_widget_event_internal(0x8321138, 0x83a7140), at 0xd17becbf 
  [44] gtk_widget_event(0x8321138, 0x83a7140), at 0xd17be951 
  [45] gtk_propagate_event(0x8321138, 0x83a7140), at 0xd16bb8f8 
  [46] gtk_main_do_event(0x83a7140, 0x0), at 0xd16ba98d 
  [47] gdk_event_dispatch(0x80cc2b8, 0x0, 0x0), at 0xd1504f7a 
  [48] g_main_dispatch(0x80cce08), at 0xd1433615 
  [49] g_main_context_dispatch(0x80cce08), at 0xd1434705 
  [50] g_main_context_iterate(0x80cce08, 0x1, 0x1, 0x8169a58), at 0xd1434b22 
  [51] g_main_loop_run(0x831e9f8), at 0xd1435124 
  [52] gtk_main(0x8046ff8, 0x8087430, 0x8160098, 0x8046d48, 0xce1d25ab, 0x81985d8), at 0xd16ba2ba 
  [53] nsAppShell::Run(0x81985d8), at 0xce2c3928 
  [54] nsAppStartup::Run(0x8160098), at 0xce1d25ab 
  [55] XRE_main(0x5, 0x8047068, 0x8087408), at 0x8061a2c 
  [56] main(0x5, 0x8047068, 0x8047080), at 0x805a521

                                    

Comments
EVALUATION

Alfred, Connie,

Could you provide us with access to the solaris box where you could reproduce the problem?
The stack trace provide isn't enough for us to debug and no one from plugin team can reproduce the problem here. Thx.
                                     
2007-03-07
EVALUATION

Even though we're not formally supporting FF2 until 5u12, I don't expect JPI to fail working with FF2 running 5u10.

However, the problem is: we cannot reproduce the problem in house.
I ran Lucent's applet with FF2, FF1.5 on solaris 9-sparc, redhat7.2-i586, and windowsXP with 5u10, 5u12, 6u1, and 7.0.
Click the left and right "arrows" on the page to reload the applet as fast as I can for hundreds of time, and no problem with applet loading, no browser hung or crashing.
Another plugin engineer (###@###.###) also helped me reproduce the problem as per description in 6510204 and in bugzilla 323175 but could not see anything wrong either.

The problem was stated to be readily reproduceable on Windows, Linux, Solaris, and Mac (sorry, we don't support Mac).
Alfred Peng from Sun Firefox Beijing team was the original person working on this bug, he stated:
"After some investigation, the hang is caused by an infinite loop in the code block of JavaVM5.cpp:
 while (spontPipeClean && (pluginInstance->GetStatus()) < APPLET_START) {
   /* Wait for the applet notify us that APPLET IS STARTED
      while waiting, we need to poll the worker queue since
      there maybe a request from java side such as cookie/proxy
      request.
    */
   ProcessWorkQueue();
 }
"

I doubt this investigation result, because this piece of code is very specific for JPI Solaris and Linux only, so it would not make sense if an infinite loop in this area would cause similar problem on Windows.

In order for us to continue our investigation, we'll need customer to provide us with:
1) java stack trace of the java_vm process when the hung happens.  To collect java stack trace:
- on solaris, download jdk5u10. Run the applet and reproduce the hang. When the hang happens, ps -ef to find pid of java_vm process.
do: <jdk5u10>/bin/jstack -m -F pid > file
- on linux, do kill -3 pid to get trace

2) java plugin trace. To collect java plugin trace on solari/linux:
- setenv JAVA_PLUGIN_TRACE 1 (prior to launching FF)
- launch FF and applet until seeing the problem.
- collect all /tmp/plugin* and /tmp/child*

3) Access to the cgi-bin and JavaScript and source code of the applet to understand the LiveConnect usage.
                                     
2007-02-14



Hardware and Software, Engineered to Work Together