Jaunty icedtea6-plugin doesn’t work in Firefox 3.5

Bug #359407 reported by Anders Kaseorg
96
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Critical
firefox-3.5 (Ubuntu)
Invalid
High
Unassigned
Jaunty
Invalid
Undecided
Unassigned
iceweasel (Debian)
Fix Released
Unknown
openjdk-6 (Ubuntu)
Fix Released
High
Michelle Armfield
Jaunty
Fix Released
High
Unassigned

Bug Description

On Jaunty amd64 with icedtea6-plugin 6b14-1.4.1-0ubuntu6, Java applets work in Firefox 3.0, but not in Firefox 3.5. The following messages show up on the console:

$ firefox-3.5
../IcedTeaPlugin.cc:3852: Error: create process
../IcedTeaPlugin.cc:1662: Error: started appletviewer

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

(firefox-3.5:13746): GLib-CRITICAL **: g_io_channel_flush: assertion `channel != NULL' failed
../IcedTeaPlugin.cc:4075: Error: Failed to flush bytes to output channel

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

(firefox-3.5:13746): GLib-CRITICAL **: g_io_channel_flush: assertion `channel != NULL' failed
../IcedTeaPlugin.cc:4075: Error: Failed to flush bytes to output channel

Tags: patch
Anders Kaseorg (andersk)
summary: - Jaunty icedtea6-plugin doesn’t work in 3.5
+ Jaunty icedtea6-plugin doesn’t work in Firefox 3.5
Revision history for this message
maxauthority (stubenschrott) wrote :

I can confirm this bug.

Anders Kaseorg (andersk)
Changed in openjdk-6 (Ubuntu):
status: New → Confirmed
Revision history for this message
TJ (tj) wrote :

As the icedtea6-plugin and openjdk-6-jre work with the 'standard' Jaunty Firefox 3.0.x this bug should be against the new, unsupported Universe package of Firefox-3.5.

Changed in firefox-3.5 (Ubuntu):
status: New → Confirmed
Changed in openjdk-6 (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
TJ (tj) wrote :

I've starting investigating this issue. The most obvious thing to notice is that the icedtea6-plugin doesn't create the named pipes in ~/icedteaplugin/ as it should.

That would explain the subsequent failure of the assertion for the gio write 'channel != NULL'. Obviously the channel is NULL and is presumably the pipe firefox should be writing to to communicate back to the plugin.

Revision history for this message
TJ (tj) wrote :

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

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

which is called during initialisation:

ICEDTEAPLUGIN_DEBUG=1 firefox-3.5

...

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
../IcedTeaPlugin.cc:3858: Error: create process
ICEDTEA PLUGIN: Instance::StartAppletviewer return
../IcedTeaPlugin.cc:1666: Error: started appletviewer
ICEDTEA PLUGIN: Factory::Initialize return

Revision history for this message
Hadrien Mary (hadim) wrote :

I have the same problem. Someone found an issues for this bug ?

Revision history for this message
fimbulvetr (fimbulvetr) wrote :

Same here. Hopefully this gets fixed soon - going from 3.5 back to 3.0 sucks!

Revision history for this message
TJ (tj) wrote :

This is a high-importance bug since any applet embedded in a web page can cause Firefox to spin the CPU at 100% until the entire Firefox process is killed.

The user has no control over the launching of a Java applet nor warning that a page contains one.

Now that firefox-3.5 takes over the /usr/bin/firefox symbolic link this becomes more invasive since any desktop shortcuts or links embedded in application configurations that expect to launch a working firefox-3.0 will launch firefox-3.5 instead.

Changed in firefox-3.5 (Ubuntu):
importance: Undecided → High
Changed in iceweasel (Debian):
status: Unknown → New
Revision history for this message
In , Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld) wrote :
Download full text (4.0 KiB)

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) 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.

../IcedTeaPlugin.cc:3858: Error: create process
../IcedTeaPlugin.cc:1666: Error: started appletviewer

(firefox-3.5:6404): GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel != NULL' failed
../IcedTeaPlugin.cc:4067: 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:

https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/359407

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

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

apt-cache policy xulrunner-1.9.1
xulrunner-1.9.1:
  Installed: 1.9.1.3+build1+nobinonly-0ubuntu0.9.04.2
  Candidate: 1.9.1.3+build1+nobinonly-0ubuntu0.9.04.2
  Version table:
 *** 1.9.1.3+build1+nobinonly-0ubuntu0.9.04.2 0
        500 http://gb.archive.ubuntu.com jaunty-proposed/universe Packages
        100 /var/lib/dpkg/status
     1.9.1.2+nobinonly-0ubuntu0.9.04.1 0
        500 http://gb.archive.ubuntu.com jaunty-updates/universe Packages
        500 http://security.ubuntu.com jaunty-security/universe Packages
     1.9.1~b4~hg20090330r24021+nobinonly-0ubuntu1 0
        500 http://gb.archive.ubuntu.com jaunty/universe Packages

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

  result = manager->CreateInstanceByContractID (NS_PROCESS_CONTRACTID,
                                                nsnull,
                                                NS_G...

Read more...

Revision history for this message
In , Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld) wrote :

Created an attachment (id=400728)
gdb backtrace full

I'm attaching a gdb full back-trace captured on the thread that was spinning the CPU at 100%.

Revision history for this message
TJ (tj) wrote :

As the Ubuntu Firefox-3.5 project doesn't have an upstream bug-tracker link defined I can't set it in this bug's header, so here's the link:

https://bugzilla.mozilla.org/show_bug.cgi?id=516671 " IcedTea/OpenJDK Java Plug-in fails; causes 100% CPU use"

It is registered against Mozilla Core -> Plugins.

Revision history for this message
In , Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld) wrote :

Created an attachment (id=400884)
gdb debug session results showing failure code

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)

returning NS_NOINTERFACE.

I'm not sufficiently expert in the spaghetti of xpcom, etc, to be able to know where or how to trace it further.

Revision history for this message
In , Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld) wrote :

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

if (NS_SUCCEEDED(rv))

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)

Changed in firefox:
status: Unknown → New
Revision history for this message
In , Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld) wrote :

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:

mozilla/testing/performance/win32/base_profile/xpti.dat:916:892,nsIProcess,{9da0b650-d07e-4617-a18a-250035572ac8},0,-1,1

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.

Revision history for this message
In , Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld) wrote :

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:

https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/359407

TJ (tj)
Changed in openjdk-6 (Ubuntu):
status: Invalid → Confirmed
importance: Undecided → High
Revision history for this message
TJ (tj) wrote :

In the upstream bug I've discovered the reason for this problem.

IcedTeaPlugin in the OpenJDK package is built against the xulrunner 1.9.0 headers and uses the nsIProcess ID from xulrunner 1.9.0: "9DA0B650-D07E-4617-...".

The problem is that xulrunner 1.9.1 has changed the Interface ID (IID) of the nsIProcess component (an additional member has been added to the interface) - it is now "D573F1F3-FCDD-4DBE-...".

As a result, when the current IcedTeaPlugin tries to create an nsIProcess component for Firefox 3.5, xulrunner 1.9.1 can't find the component and returns NS_NOINTERFACE.

I'm exploring whether IcedTeaPlugin could be patched to query the nsIProcess interface to select the correct IID to use, or else catch this error and try the newer IID before giving up.

Revision history for this message
John Vivirito (gnomefreak) wrote :

When you say "upstream bug" what bug are you talking about?

Revision history for this message
TJ (tj) wrote :

The bug referred to in my comment #8 and linked against Mozilla Firefox.

I've got a relatively simply patch in the works, although its a slight kludge.

In IcedTeaPluginFactory::StartAppletViewer() it will check the run-time xulrunner platform version and choose the IID to request (from the one provided by the 1.9.0 headers, or the explicitly coded 1.9.1 IID).

It should make the patch about 8 lines if everything I've read up on, and checked with the xulrunner dev's on IRC, proves correct.

Revision history for this message
TJ (tj) wrote :

Confirmation that a trivial patch solves this issue.

ICEDTEAPLUGIN_DEBUG=1 firefox-3.5
...
ICEDTEA PLUGIN: Instance::StartAppletviewer
ICEDTEA PLUGIN: get component manager
ICEDTEA PLUGIN: create local file
ICEDTEA PLUGIN: init with path
ICEDTEA PLUGIN: create process
ICEDTEA PLUGIN: init process
ICEDTEA PLUGIN: clearing old input fifo (if any): /home/tj/.icedteaplugin/icedtea-appletviewer-to-plugin
ICEDTEA PLUGIN: creating input fifo: /home/tj/.icedteaplugin/icedtea-appletviewer-to-plugin
ICEDTEA PLUGIN: created input fifo: /home/tj/.icedteaplugin/icedtea-appletviewer-to-plugin
ICEDTEA PLUGIN: got confirmation that appletviewer is running
ICEDTEA PLUGIN: clearing old output fifo (if any): /home/tj/.icedteaplugin/icedtea-plugin-to-appletviewer
ICEDTEA PLUGIN: creating output fifo: /home/tj/.icedteaplugin/icedtea-plugin-to-appletviewer
ICEDTEA PLUGIN: created output fifo: /home/tj/.icedteaplugin/icedtea-plugin-to-appletviewer
ICEDTEA PLUGIN: run process
Listening for transport dt_socket at address: 8787
ICEDTEA PLUGIN: Instance::StartAppletviewer return
...

In summary, The Jaunty version of openjdk-6 IcedTeaPlugin is built against the xulrunner 1.9.0.x dev headers (which Firefox 3.0.x uses). IcedTeaPlugin creates an instance of nsIProcess using the Interface ID (IID) declared in those headers. The nsIProcess object then loads and manages the JVM in another process.

Firefox 3.5 uses xulrunner 1.9.1.x, which has 'unfrozen' the nsIProcess interface definition and consequently changed the IID. Therefore when xulrunner 1.9.1 is asked to create the nsIProcess object by IcedTeaPlugin it fails since the old xulrunner 1.9.0 IID doesn't exist.

I've patched IcedTeaPlugin.cc to query the IID of nsIProcess at run-time rather than use the build-time definition. I've tested the same IcedTeaPlugin.so with Firefox 3.0 and 3.5 and both work correctly, starting the applet.

I've found there is a subsequent exception once the Sun Java test applet is running which needs a separate investigation:

ICEDTEA PLUGIN: Instance::ConsumeMsgFromJVM
received message: instance 1 status exception: java.lang.StringIndexOutOfBoundsException: String index out of range: 8.
Processing complete
ICEDTEA PLUGIN: Instance::ConsumeMsgFromJVM return

However, other sophisticated Java applets are working fine on Firefox 3.5 now.

I will attach a patch and debdiff with the fix and publish a fixed version of openjdk-6 to my PPA.

Because it takes so long to build openjdk and its a lot of overkill for building just IcedTeaPlugin I'll also build just the IcedTeaPlugin.so for i386 and amd64 and host them where they can easily be tested by backing up the current shared object:

/usr/lib/jvm/java-6-openjdk/jre/lib/{i386,amd64}/IcedTeaPlugin.so

and replacing it with the new one.

Revision history for this message
TJ (tj) wrote :
Revision history for this message
TJ (tj) wrote :
Revision history for this message
Matthias Klose (doko) wrote :
Changed in openjdk-6 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
TJ (tj) wrote :

The patch is intended as a specific patch for the Ubuntu Jaunty (and related Debian) openjdk package since it is supposed to support the use of the IcedTeaPlugin in both Firefox-3.0 and Firefox-3.5, but being built against the xulrunner 1.9.0 headers, fails in respect of the nsIProcess IID as I describe.

In later packages of openjdk (Karmic, etc) this issue should no longer be a problem since the default Firefox will be 3.5 and xulrunner 1.9.1+, and the IcedTea/OpenJDK packages are similarly up to date and don't make use of xulrunner 1.9.0 headers.

Changed in firefox:
status: New → Invalid
TJ (tj)
Changed in openjdk-6 (Ubuntu):
status: Incomplete → Confirmed
Matthias Klose (doko)
Changed in openjdk-6 (Ubuntu):
status: Confirmed → Invalid
Changed in openjdk-6 (Ubuntu Jaunty):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openjdk-6 - 6b16-1.6.1-1ubuntu1

---------------
openjdk-6 (6b16-1.6.1-1ubuntu1) karmic; urgency=low

  * Fix dependency on the java bridge packages.
  * debian/rules: Conditionalize stuff so that the recent release
    is never mentioned.
  * Remove obsolete patches in debian/patches.
  * Rebuild on armel to fix up libffi for the soft float abi.
  * For jaunty builds, fix IcedTeaPlugin failure to start with xulrunner 1.9.1
    (LP: #359407).
    - debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff: Add.
    - debian/rules: Apply it for jaunty builds.
  * Use pulseaudio as default serviceprovider for
    javax.sound.midi.MidiSystem and javax.sound.sampled.AudioSystem.
    LP: #407299.

 -- Matthias Klose <email address hidden> Sat, 26 Sep 2009 16:01:48 +0200

Changed in openjdk-6 (Ubuntu):
status: Invalid → Fix Released
Revision history for this message
Alexander Sack (asac) wrote :

i am not sure why openjdk would want to use the nsIProcess IID directly. Can you elaborate?

Revision history for this message
tlu (thomas-ludwig-gmx) wrote :

I just noticed that openjdk 6b16-1.6.1-1ubuntu3 freezes Firefox 3.5.4 (and 3.5.5 from the ppa) in Karmic in a reproducible manner whenever I try to open a site requiring java. The only hint I was able to find is the following line in .xsession-errors:

/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/../../bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Perhaps an error in the 64bit version?

Revision history for this message
Robert Lange (rcl24) wrote :

I am using Jaunty 32-bit with Firefox 3.5 (3.5.7+nobinonly-0ubuntu0.9.04.1) from the Ubuntu Universe repository and OpenJDK/IcedTea (6b16-1.6.1-0jaunty1) from the OpenJDK PPA (https://launchpad.net/~openjdk/+archive/ppa). I have never had Sun JDK or GCJ installed on this system.

None of the Java applets I have tried work (for example, http://www.java.com/en/download/help/testvm.xml).

Prior to installing OpenJDK 1.6.x from the OpenJDK PPA (when I was using OpenJDK 1.4.x that came with the official Jaunty repositories) when I loaded a Java applet, Firefox would hang at 100% CPU and nothing but a grey box would appear in place of the applet. I would have to manually kill the Firefox process.

Now that I am using OpenJDK 1.6.x, Firefox does not hang upon attempting to load the applet, but still only shows the grey box. I can still do all other Firefox operations normally. I still get error messages on the terminal identical to those shown in this bug report. When I close Firefox, the Firefox process hangs, and I have to manually kill it before starting a new Firefox instance.

So from what I can see, the OpenJDK/IcedTea 1.6.x packages in the OpenJDK PPA do nothing for this bug except delay the hang until you attempt to close the Firefox instance. Can someone confirm whether simply adding the OpenJDK PPA and dist-upgrading to OpenJDK 1.6.x is enough to fix this? Do I have to do any extra voodoo like first remove and purge all of Firefox/OpenJDK/world? Do I have to manually delete any directories or symlinks? I have not done any manual mucking around with the Firefox or OpenJDK stuff, and was hoping that simply letting apt do the upgrade would be sufficient, but apparently it's not.

Revision history for this message
Klaus (klaus-p-koch) wrote :

Launchpad Janitor wrote on 2009-09-26: #17
> This bug was fixed in the package openjdk-6 - 6b16-1.6.1-1ubuntu1
> ---------------
> openjdk-6 (6b16-1.6.1-1ubuntu1) karmic; urgency=low

Does this mean the bug was fixed in Karmic, but not in Jaunty (for which it was reported)?
I installed openjdk-6-jre (6b14-1.4.1-0ubuntu12) and icedtea6-plugin (6b14-1.4.1-0ubuntu12) from the current repository but there's still no java in Firefox 3.5/3.6 (in Firefox 3.0.8 it works.)
Karmic does not like my notebook, that's why I have to stick with Jaunty.
Are there any dependencies in Jaunty that prevent the fixed openjdk from being incorporated into the repository?

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Is https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/452413 a duplicate of this?

Karmic icedtea6-plugin works on my 32-bit machine, but not my 64-bit one.

Changed in iceweasel (Debian):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (17.9 KiB)

This bug was fixed in the package openjdk-6 - 6b18-1.8-4ubuntu3~9.04.2

---------------
openjdk-6 (6b18-1.8-4ubuntu3~9.04.2) jaunty-security; urgency=low

  * Upload to Jaunty

openjdk-6 (6b18-1.8-4ubuntu3) lucid-proposed; urgency=low

  * Update from the 1.8 branch.
  * Rebuild with fixed ant.
  * Disable building the shark based VM on armel.
  * Always build the ARM assembler interpreter in arm mode.

openjdk-6 (6b18-1.8-4) unstable; urgency=low

  * Update from the 1.8 branch.
    - Plugin and netx fixes.
    - Don't link the plugin against the libxul libraries. Closes: #576361.
    - More plugin cpu usage fixes. Closes: #584335, #587049.
    - Plugin: fixes AppletContext.getApplets().
    - Fix race conditions in plugin initialization code that were causing
      hangs when loading multiple applets in parallel.
  * Fix Vcs-Bzr location. Closes: #530883.
  * Search for unversioned llvm-config tool.
  * Don't set XFILESEARCHPATH and NLSPATH on startup. LP: #586641.
  * Fix chinese font metrics and prefer using 'WenQuanYi Micro Hei' font.
    LP: #472845.
  * Strip libjvm.so with --strip-debug instead of --strip-unneeded.
    LP: #574997.
  * Don't turn on the ARM assembler interpreter when building the shark
    VM.

openjdk-6 (6b18-1.8-3) unstable; urgency=low

  * Update from the 1.8 branch.
    - Plugin fixes. LP: #597714.
  * Add powerpcspe build fixes (Sebastian Andrzej Siewior). Closes: #586359.
  * Work around build failure on buildds configured with low ARG_MAX
    (Giovanni Mascellani). Closes: #575254.

openjdk-6 (6b18-1.8-2ubuntu2) maverick; urgency=low

  * Search for unversioned llvm-config tool.

openjdk-6 (6b18-1.8-2ubuntu1) maverick; urgency=low

  * Upload to maverick.

openjdk-6 (6b18-1.8-2) unstable; urgency=low

  * Update from the 1.8 branch.
    - Fix build on Hitachi SH. Closes: #575346.
    - Shark and Zero fixes.
  * Build shark using llvm-2.7.
  * Don't use shark to run the test harness when testing the shark build.
  * README.Debian: Add paragraph about debugging the IcedTea NPPlugin.

openjdk-6 (6b18-1.8-1) unstable; urgency=low

  * Upload to unstable.

openjdk-6 (6b18-1.8-0ubuntu1) lucid; urgency=low

  * Update IcedTea6 to the icedtea6-1.8 release.
  * Fix builds on Ubuntu/dapper and Debian/lenny.
  * On hppa, configure --without-rhino --disable-plugin.
  * Fix Hitachi SH configury. Closes: #575346.
  * Start a window manager when running the tests. Prefer metacity,
    as more tests pass with it.
  * Let XToolkit.isTraySupported() return true, if Compiz is running.
    Works around sun#6438179. LP: #300948.
  * Make <java_home>/jre/lib/security/nss.cfg a config file.
  * Fail in the configuration of the packages, if /proc is not mounted.
    java currently uses tricks to find its own shared libraries depending
    on the path of the binary. Will be changed in OpenJDK7. Closes: #576453.
  * Fix PR icedtea/469, testsuite failures with the NSS based security
    provider. LP: #556549.
  * Do not pass LD_LIBRARY_PATH from the plugin to the java process.
    While libnss3.so gets loaded from /usr/lib, the dependent libraries
    are loaded from MOZILLA_FIVE_HOME (See #561216 for the wrong firefox
    config). LP: ...

Changed in openjdk-6 (Ubuntu Jaunty):
status: Confirmed → Fix Released
papukaija (papukaija)
tags: added: patch
Revision history for this message
Matthias Klose (doko) wrote :

this doesn't need fixes in firefox. firefox-3.6 is now in jaunty and newer releases. the plugin works with this version of firefox

Changed in firefox-3.5 (Ubuntu):
status: Confirmed → Invalid
Changed in firefox-3.5 (Ubuntu Jaunty):
status: New → Invalid
Changed in firefox:
importance: Unknown → Critical
Changed in openjdk-6 (Ubuntu):
assignee: nobody → Michelle Armfield (mstrs41658)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.