JDK-6510204 : Java applets load repeatedly hangs Firefox
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u11,6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_nevada,solaris_10
  • CPU: generic,x86
  • Submitted: 2007-01-05
  • Updated: 2010-12-06
  • Resolved: 2008-01-28
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.
Other JDK 6
5.0u15Fixed 6u10 b02Fixed
Test case:

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

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

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.

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.