Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160543 - Mozilla java plugin fails
Summary: Mozilla java plugin fails
Alias: None
Product: Fedora
Classification: Fedora
Component: mozilla
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Christopher Aillon
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-15 18:01 UTC by Mark Patton
Modified: 2018-04-11 08:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-30 13:14:18 UTC

Attachments (Terms of Use)

Description Mark Patton 2005-06-15 18:01:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
The sun java plugin fails silently when a java applet is accessed with firefox. The plugin is present and java is enabled in firefox. (Verified with about:plugins.)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install sun jdk1.5.0_03
2. Update /etc/alternatives
3. In plugin dir, ln -s /opt/jdk1.5.0_03/jre/plugin/i386/ns7/
4. Start mozilla
5. Try java applet such as

Actual Results:  The applet fails silently. A log file plugin_stack.trace is produced in the home directory. It contains a stack trace:

        at sun.plugin.AppletViewer.initEnvironment(
        at sun.plugin.navig.motif.Plugin.doit(
        at sun.plugin.navig.motif.Plugin.start(

Expected Results:  The applet should run.

Additional info:

Comment 1 Richard Lloyd 2005-06-16 20:22:47 UTC
Just a note that I'm seeing exactly the same thing with Firefox 1.0.4 on the
x86_64 release of Fedora Core 4 as well. I tried it with both 32-bit and 64-bit
Firefoxes and Sun JVMs (and tried JVM 1.4.2_08 as well as JVM 1.5.0_03) and none
of the combinations worked. Yes, I have the multilib stuff installed before you ask.

This failure is somewhat unfortunate because the average end-user thinks of
applets when you mention Java, but FC4 not only doesn't ship with any Java
plug-in for FC4's Web browsers, but it won't let you install Sun's Java RPM if
you have all the GCJ stuff installed (conflicts on naming conventions) and if
you decide to unpack Sun's JRE .tar.gz instead, their plug-in doesn't even work

BTW, the FC4 release notes are quite vague about this - "go and install the RPM
from" (er, which one - there's 1500+ RPMs there) or "unpack Sun's
Java into /opt" (why not into /usr/java where the RPM would install it into?).
So is there a workaround for this problem? I've even been contemplating
gcjwebplugin, but it looks insecure (and needs a minor source tweak to build
with g++ 4.0 anyway - int vs. long issue).

Oh and I'd like to suggest that the priority or severity of this gets raised a
bit - after the excellent set of Java-related goodies shipped with FC4, this bug
is letting down the overall Java quality of FC4 in a fairly high profile manner.

Comment 2 Michael Charnoky 2005-06-17 14:27:00 UTC
I too am experiencing this problem on a 32-bit Athlon system, using JDK 1.5.0_03
(installed from .bin not RPM).  As a java developer I agree that this is really
bad news.  I really need to access the custom java applets that our company has
developed on a day-to-day basis.  Unfortunately, I can't seem to boot from my
old FC3 partition now, as GRUB is giving me an error here :^(

I have exchanging notes with folks at the fedora forum to try and resolve this:

Here are some things I have tried, to no avail:

* Removed all fedora java related RPMs: gcj, gcjlib, jvm and all dependencies. I
even had to delete openoffice since it depends on this java stuff. I think I
have removed everything java related... I did an "rpm -qa" and grepped for
"java", "gcj", "jpp", "jakarta", "commons", etc.

* Created a fresh new user account. I thought that some old firefox preferences
might have been mucking up the works.

* Tried mozilla instead of firefox. Again, "about:plugins" shows that the Java
plugin is apparently installed. But, if I try to load a page with an applet I
see a blank box with a puzzle piece icon. If I right click on the icon I get a
popup with the text: "This page contains information of a type
(application/x-java-vm) that can only be viewed with the appropriate plugin".
Yet, the plugin config page for firefox/mozilla lists that MIME type. Very

Comment 3 Warren Togami 2005-06-17 20:06:14 UTC
Removing Fedora's java RPMS is unnecessary and will not help you at all.

I just tried it again, unpacked into /opt/jre1.5.0_03 and symlinked -> /opt/jre1.5.0_03/plugin/i386/ns7/
Firefox i386 is working fine for me.

Comment 4 Mark Patton 2005-06-17 20:23:38 UTC
I have installed FC4 twice and this problem was present both times.

The stack trace shows that a class wasn't able to be found. Perhaps there's an
issue with the classpath being set?

I tried removing all the java packages and setting the firefox config option
java.default_java_location_others to my jdk install without any success.

Comment 5 BandC 2005-06-17 23:16:47 UTC
It seems to be the difference between JDK and JRE. Looks like JRE works fine (I
haven't tried it, I just read posts) and JDK doesn't.

Comment 6 Andre Robatino 2005-06-17 23:45:41 UTC
  I have the bug with the JRE.  I think you're seeing a misleading correlation -
the problem probably has to do with certain Fedora Java packages being
installed, and the same people who install these are the ones using the JDK
instead of the JRE.

Comment 7 Michael Charnoky 2005-06-18 01:43:52 UTC
I have tried both the JDK and the JRE.  No dice getting the java plugin to work
using either one.  I need the JDK to do actual Java development work, which is
why I tried it first.  FYI: the JDK is basically the same as the JRE, but then
adds more stuff like javac to allow development.  I'm back to FC3 now, so I can
actually get work done :^(

Comment 8 Andre Robatino 2005-06-18 20:31:00 UTC
  My plugin_stack.trace file is slightly different:

        at sun.plugin.AppletViewer.initEnvironment(Unknown Source)
        at sun.plugin.navig.motif.Plugin.doit(Unknown Source)
        at sun.plugin.navig.motif.Plugin.start(Unknown Source)

  Is the fact that the argument in my case is "Unknown Source" due to my not
setting the right Java environment variables, or a clue?

Comment 9 Andre Robatino 2005-06-19 08:01:12 UTC
  I was able to build Java RPMs which work using the instructions at

which I found out about from

  As mentioned it's safer to do the rpmbuild as an ordinary user in one's home
directory.  It was reasonably easy even though I've never done it before
(finding a good set of instructions makes all the difference).  This should take
the heat off some developers while this bug is tracked down.

Comment 10 Andre Robatino 2005-06-19 19:19:27 UTC
  See post #45 at

for how one person fixed the problem after guessing it was related to SELinux.

Comment 11 Mark Patton 2005-06-20 12:01:14 UTC
I fixed the problem by running /sbin/fixfiles relabel. If you look at audit.log,
selinux had not labeled the java libraries as libraries.

Comment 12 BandC 2005-06-20 23:00:54 UTC
I'm happy to report that the latest SELinux update from updates-released I just
applied fixed this problem for me.

Comment 13 Andre Robatino 2005-06-20 23:52:32 UTC
  It's also fixed for me.  BTW, when I uninstalled the java RPMs I had built
earlier, it messed up the alternatives symlinks, so I would recommend people
just install the self-extracting .bin file.

Comment 14 Habig, Alec 2006-04-02 14:58:53 UTC
This bug's back with FC5, selinux-policy-targeted-2.2.25-2.fc5

The java plugin works if I turn off enforcing, doesn't if I do (same plugin
trace as above, audit logs confirm that selinux is stopping things).

fixfiles does nothing, but if the policy is wrong then I guess it doesn't know
what to do anyway.

Comment 15 Markus Mottl 2006-04-10 01:17:29 UTC
(In reply to comment #14)
> This bug's back with FC5, selinux-policy-targeted-2.2.25-2.fc5
> The java plugin works if I turn off enforcing, doesn't if I do (same plugin
> trace as above, audit logs confirm that selinux is stopping things).
> fixfiles does nothing, but if the policy is wrong then I guess it doesn't know
> what to do anyway.

I was able to fix this problem by following these steps:

If you have not already done so go to "System" > "Administration" > "Security
Level and Firewall". Enter your root password and click "ok". On the "SELinux"
tab click on "Modify SELinux Policy", click on "Compatibility" to open it and
tick the check box next to "Allow the use of shared libraries with Text
Relocation". Click "ok". Reboot your machine to implement the new SELinux policy.

I found this hint here:

Java works like I charm now on my machine...

Comment 16 Andre Robatino 2006-04-10 01:53:01 UTC
  I'm experiencing this on FC5 with selinux-policy-targeted-2.2.25-3.fc5 and
Sun's 1.5.0_06 JRE, using the self-extracting .bin file.  Below are errors from

audit(1144633562.709:8): avc:  denied  { execmod } for  pid=4430 comm="java_vm"
name="" dev=dm-0 ino=2749855
scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:usr_t:s0
audit(1144633563.537:9): avc:  denied  { execmod } for  pid=4446 comm="java_vm"
name="" dev=dm-0 ino=2749855
scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:usr_t:s0
audit(1144633564.329:10): avc:  denied  { execmod } for  pid=4462 comm="java_vm"
name="" dev=dm-0 ino=2749855
scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:usr_t:s0
audit(1144633565.016:11): avc:  denied  { execmod } for  pid=4478 comm="java_vm"
name="" dev=dm-0 ino=2749855
scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:usr_t:s0

Comment 17 Habig, Alec 2006-04-19 17:54:35 UTC
Anybody know what the setsebool parameter in question for the above "Allow the
use of shared libraries with Text Relocation" suggestion is, for us command line

Here's something else which works:

  chcon -t textrel_shlib_t /usr/local/jre1.5.0_06/lib/i386/

which sets the context needed to allow that one specific offending library to do
what it needs, without allowing all libraries on the system to also do so.

Comment 18 James Burke 2006-05-29 00:03:20 UTC
32-bit and I followed the java guide on fedorafaq to install made rpms for -- I also submitted a bug to mozilla foundation-

there i mention that i have an i386 32-bit

my system is fedora core 5 -- i have no java variables needed to setup-- java
version shows properly in about:plugins (firefox of course)..

no applets work-- however rm or mv ~/.mozilla works

note: I do not have SELinux=disabled and I have disabled it since fc4 I also
have no clue what this works so I'm filling this to both mozilla and fedora's
bugzilla..hopefully someone will determine soon what's causing this..


Comment 19 James Burke 2006-05-29 00:05:19 UTC
sorry -- I meant I have SELINUX=disabled  --- ://

Comment 20 Christian Iseli 2007-01-22 11:55:16 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


Comment 21 Matěj Cepl 2007-07-18 17:24:21 UTC
Distribution against which this bug was reported is no longer supported; could
you please reproduce this with the updated version of the currently supported
distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue turns out
to still be reproducible, please let us know in this bug report.  If after a
month's time we have not heard back from you, we will have to close this bug as

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.

Comment 22 Habig, Alec 2007-07-27 15:22:26 UTC
I just tested FC6, sun's Java 1.6.0_02, and seamonkey-1.0.9-2.fc6.  It worked
just fine, so looks like selinux is behaving itself now, and IMHO this bug seems

Comment 23 Matěj Cepl 2007-07-30 13:14:18 UTC
Thanks a lot for letting us know.

Note You need to log in before you can comment on or make changes to this bug.