Closed Bug 516671 Opened 15 years ago Closed 15 years ago

IcedTea/OpenJDK Java Plug-in fails; causes 100% CPU use


(Plugins Graveyard :: Java (IcedTea), defect)

Not set


(Not tracked)



(Reporter: bugzilla.mozilla, Unassigned)





(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3

Loading any page containing a Java applet causes a failure in the IcedTea Java plug-in <> xulrunner interface resulting in 100% core usage, and requiring a hard 'kill -9' of the firefox process.

Reproducible: Always

Steps to Reproduce:
1. Use the IcedTea Plugin and OpenJDK Java environment
2. Start Firefox 3.5.x
3. Visit a page containing a Java applet

Actual Results:  
CPU core runs at 100% and can only be stopped if the browser process is sent the SIGKILL signal - SIGTERM/closing the application doesn't remove the process from memory or stop the CPU spinning.

../ Error: create process
../ Error: started appletviewer

(firefox-3.5:6404): GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel != NULL' failed
../ Error: Failed to write bytes to output channel

The last GLib-CRITICAL message is repeated.

Expected Results:  
The plug-in should start, CPU usuage should be minimal,the Java applet should run, and the application should exit memory correctly.

This doesn't affect Firefox 3.0.x.

Originally reported on Ubuntu Launchpad:

apt-cache policy icedtea6-plugin
  Installed: 6b14-1.4.1-0ubuntu11
  Candidate: 6b14-1.4.1-0ubuntu11
  Version table:
 *** 6b14-1.4.1-0ubuntu11 0
        500 jaunty-updates/main Packages
        500 jaunty-security/main Packages
        100 /var/lib/dpkg/status
     6b14-1.4.1-0ubuntu7 0
        500 jaunty/main Packages

apt-cache policy openjdk-6-jre
  Installed: 6b14-1.4.1-0ubuntu11
  Candidate: 6b14-1.4.1-0ubuntu11
  Version table:
 *** 6b14-1.4.1-0ubuntu11 0
        500 jaunty-updates/main Packages
        500 jaunty-security/main Packages
        100 /var/lib/dpkg/status
     6b14-1.4.1-0ubuntu7 0
        500 jaunty/main Packages

apt-cache policy xulrunner-1.9.1
  Version table:
 *** 0
        500 jaunty-proposed/universe Packages
        100 /var/lib/dpkg/status 0
        500 jaunty-updates/universe Packages
        500 jaunty-security/universe Packages
     1.9.1~b4~hg20090330r24021+nobinonly-0ubuntu1 0
        500 jaunty/universe Packages

Using debug information from icedtea the problem appears to stem from "Error: create process":

  result = manager->CreateInstanceByContractID (NS_PROCESS_CONTRACTID,
                                                NS_GET_IID (nsIProcess),
                                                getter_AddRefs (applet_viewer_process));
  PLUGIN_CHECK_RETURN ("create process", result);

which is called during initialisation:



Initializing JVM...
ICEDTEA PLUGIN: get component manager
ICEDTEA PLUGIN: liveconnect
ICEDTEA PLUGIN: thread manager
ICEDTEA PLUGIN: Instance::StartAppletviewer
ICEDTEA PLUGIN: get component manager
ICEDTEA PLUGIN: create local file
ICEDTEA PLUGIN: init with path
../ Error: create process
ICEDTEA PLUGIN: Instance::StartAppletviewer return
../ Error: started appletviewer
ICEDTEA PLUGIN: Factory::Initialize return

It appears that the xulrunner-1.9.1 plug-in handling code has changed subtly, since the IcedTea plug-in works fine with Firefox 3.0.x and xulrunner
Attached file gdb backtrace full
I'm attaching a gdb full back-trace captured on the thread that was spinning the CPU at 100%.
I've managed to trace into nsComponentManagerImpl::CreateInstanceByContractID() and find where the problem is occurring, but not *why*:

I've attached a cleaned up version of a gdb session that ends with the call to 

factory->CreateInstance(aDelegate, aIID, aResult)


I'm not sufficiently expert in the spaghetti of xpcom, etc, to be able to know where or how to trace it further.
A little more exploration. In nsComponentManagerImpl::CreateInstanceByContractID() I found that entry->GetFactory() is returning NS_ERROR_INVALID_POINTER.

What seems strange is that the following


seems to be returning TRUE since the code inside the block gets executed.

1664	    nsFactoryEntry *entry = GetFactoryEntry(aContractID, strlen(aContractID));
(gdb) n
1666	    if (!entry)
(gdb) n
1681	    nsIFactory *factory = nsnull;
(gdb) n
1682	    nsresult rv = entry->GetFactory(&factory);
(gdb) n
1684	    if (NS_SUCCEEDED(rv))
(gdb) display entry
2: entry = <value optimized out>
(gdb) display factory
3: factory = (class nsIFactory *) 0x7f345b2982e0
(gdb) print /x rv
$2 = 0x80004003

#define NS_ERROR_INVALID_POINTER           ((nsresult) 0x80004003L)
I believe I've found the problem. I was reviewing the two NS_ errors alongside reading up on the XPCOM programming book/tutorial.

Looking at the introduction to interface IIDs it reminded me of NS_NOINTERFACE found in comment #2.

I looked at the gdb debug log where I examined the aIID parameter:

8: aIID = (const nsIID &) @0x7fe6c50c2ca0: {m0 = 2644555344, m1 = 53374, m2 = 17943, m3 = "�\212%\0005W*�"}

I converted the first three parts (m0,m1,m2) to hex: 9DA0B650-D07E-4617-

Then I searched the source-code for the UUID.

In xulrunner-1.9.1 I could only find it in:


I looked at the xulrunner 1.9.1 "xpcom/threads/nsIProcess.idl" and found nsIProcess has the IID "D573F1F3-FCDD-4DBE-...":

[scriptable, uuid(d573f1f3-fcdd-4dbe-980b-4ba79e6718dc)]
interface nsIProcess : nsISupports

Looking at the xulrunner 1.9.0 "xpcom/threads/nsIProcess.idl" I found:

[scriptable, uuid(9da0b650-d07e-4617-a18a-250035572ac8)]
interface nsIProcess : nsISupports

This matches the IID requested by IcedTeaPlugin, "9DA0B650-D07E-4617-*"

I looked at the differences in the interface descriptions of the two versions. It seems that apart from all the additional comments, the 1.9.1 interface has an additional member:

readonly attribute boolean isRunning;

Can an XPCOM expert confirm I've interpreted this information correctly?

If it is correct it has implications for the IcedTea/OpenJDK builds since to support both versions of xulrunner there would need to be two versions of the IcedTea Plugin built, one against the xulrunner 1.9.0 headers and the other against the 1.9.1 headers.

Would patching IcedTeaPlugin with additional code to detect the interface version at run-time and choosing the IID to pass based on that be sufficient to work around this issue, allowing one IcedTea/OpenJDK build to service both xulrunner versions?

This is something I'll investigate.
I've now confirmed the problem is the use of the static build-time IID for nsIProcess in the IcedTeaPlugin StartAppletviewer() method, combined with it including the headers from xulrunner 1.9.0, resulting in the wrong IID being requested when running with xulrunner 1.9.1.

I've created a patch on IcedTeaPlugin that requests the run-time IID and requests that. Details are in the Ubuntu bug report:
Closed: 15 years ago
Resolution: --- → INVALID
Component: Plug-ins → Java (IcedTea)
Product: Core → Plugins
QA Contact: plugins → icedtea-java
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.