Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 56990

Summary: Java/JRE takes about 5 minutes to load an applet
Product: Gentoo Linux Reporter: Tom Wesley <tom>
Component: Current packagesAssignee: Java team <java>
Status: RESOLVED CANTFIX    
Severity: major    
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Not workiong output of iptables -L generated by shorewall
working version created by firestarter

Description Tom Wesley 2004-07-14 00:46:57 UTC
I have developed a problem starting Java applets, and debugging it is getting out of my league, although I'm hoping that I have some information that will help someone more experienced in these matters.

If I try to start either a Java applet on a web page or a Java application then it will take about 5 minutes for anything to happen.  This is not the time it takes to load the plugin, as I hope to demonstrate:

Since the ControlPanel also gives the same problem and is easily run from the command line I have tried to strace and find the problem.
The full log is 86MB in size, so probably not wise to attach here, but I have noticed that there are many many lines like the following:

[pid 17123] ioctl(8, FIONREAD[pid 17123] ioctl(8, FIONREAD, [0])     = 0
, [0])     = 0

All with the same PID, and set of
[pid 17123] poll([pid 17123] poll( <unfinished ...>
[pid 17121] <... nanosleep resumed> NULL) = 0
[pid 17123] <... poll resumed> [{fd=8, events=POLLRDNORM}], 1, 1) = 0
 <unfinished ...>
[pid 17121] <... nanosleep resumed> NULL) = 0
[pid 17123] <... poll resumed> [{fd=8, events=POLLRDNORM}], 1, 1) = 0

with differing PID's, and similarly
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 412889}, NULL) = 0
{1089790027, 412889}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 413413}, NULL) = 0
{1089790027, 413413}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 413588}, NULL) = 0
{1089790027, 413588}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 413639}, NULL) = 0
{1089790027, 413639}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 413736}, NULL) = 0
{1089790027, 413736}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 413843}, NULL) = 0
{1089790027, 413843}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 414070}, NULL) = 0
{1089790027, 414070}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 414127}, NULL) = 0
{1089790027, 414127}, NULL) = 0
[pid 17123] <... poll resumed> [{fd=8, events=POLLRDNORM}], 1, 1) = 0
[pid 17123] <... poll resumed> [{fd=8, events=POLLRDNORM}], 1, 1) = 0
[pid 17123] ioctl(8, FIONREAD[pid 17123] ioctl(8, FIONREAD, [0])     = 0
, [0])     = 0
[pid 17123] ioctl(8, FIONREAD[pid 17123] ioctl(8, FIONREAD, [0])     = 0
, [0])     = 0
[pid 17123] poll([pid 17123] poll( <unfinished ...>
[pid 17113] gettimeofday( <unfinished ...>
[pid 17113] gettimeofday({1089790027, 414843}, NULL) = 0
{1089790027, 414843}, NULL) = 0
[pid 17113] gettimeofday([pid 17113] gettimeofday({1089790027, 415407}, NULL) = 0


Does anyone have enough info to offer any idea as to what is going on?

Cheers,


Reproducible: Always
Steps to Reproduce:
1. strace -f ./ControlPanel




Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0,
2.6.7-gentoo-r9)
=================================================================
System uname: 2.6.7-gentoo-r9 i686 AMD Athlon(tm) MP 2400+
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-mp -O2 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-mp -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/
http://ftp.snt.utwente.nl/pub/os/linux/gentoo
http://ftp6.uni-erlangen.de/pub/mirrors/gentoo
http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.blueyonder.co.uk
http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://ftp.du.se/pub/os/gentoo http://ftp.caliu.info/pub/gentoo/
http://ftp.heanet.ie/pub/gentoo/"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/overlays/bmg-main.alternative/ /usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dfx 3dnow X alsa apm avi berkdb cdr crypt cups dga dvd dvdr encode
foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 java jpeg libg++
libwww mad mikmod motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls
nntp offensive oggvorbis opengl oss pam pda pdflib perl png python quicktime
readline sdl slang spell ssl svga tcpd tiff truetype x86 xine xml2 xv zlib"
Comment 1 Tom Wesley 2004-07-14 12:56:55 UTC
OK, some additional information thanks to DrChandra in chat.  Seems to have been related to the repeated poll:

socket(PF_UNIX, SOCK_STREAM, 0[pid 17113] socket(PF_UNIX, SOCK_STREAM, 0) = 8
[pid 17113] connect(8, {sa_family=AF_UNIX, path="/tmp/.X11-unix/X0"}, 19[pid 17113] connect(8, {sa_family=AF_UNIX, path="/tmp/.X11-unix/X0"}, 19) = 0

So it looks as though something is trying to connect to the X server.

Also, the full 86MB strace log bzip2's to ~500K if it will be of use to anyone.
Comment 2 Tom Wesley 2004-07-16 13:24:34 UTC
OK, seems it was a recent update to shorewall that caused the problem.  Stopping shorewall didn't solve the problem, but restarting after removing it from the runlevel did.  I'd love to know why, if anyone knows why?
Comment 3 Greg Tassone 2004-08-07 14:17:42 UTC
It makes sense that it was trying to connect to X -- the Control Panel requires X and should need to connect, yes?

In any case, I'm not sure why the apparent conflict exists with shorewall -- I don't use it.  However, I didn't see listed which JVM (runtime) you are using.  Maybe throwing that out would be helpful to someone, at the least.
Comment 4 Tom Wesley 2004-08-07 14:23:35 UTC
I tried pretty much all of the JVM/JRE's in portage, including the beta 1.5 from Sun.  It's perfectly replicatable here, and is probably something I am doing with shorewall.  If someone wants to try then use the webmin configuration for shorewall (latest ~2.0.6 still has the problem) and set it up for a single interface to the internet, not other card at all.
Comment 5 Greg Tassone 2004-08-07 15:28:32 UTC
Almost certainly what is happening here is that Shorewall is blocking your local X server connections.  The ControlPanel needs an X connection to launch, but for some reason either Shorewall or IPTables in the kernel is blocking it.

I'm assuming that you can launch other applications just fine.  In that case, it may have something specific to do with the way X sockets are used by Java runtimes, but I'm not sure.

I suggest taking a look at your IPTables rules after Shorewall starts.  It is probably inserting a bunch or rules, one of which is blocking the JRE from accessing the X server.  This would also explain why rebooting after stopping shorewall seemed to allow normal connections again.

You can usuaully view IPTables rules by using the following command:

iptables -L

Further debugging may need to be done with iptables folks.  But it seems almost certain that this is the problem.  If so, it's not Java's fault and this issue should be reassigned or resolved.
Comment 6 Tom Wesley 2004-08-07 15:38:51 UTC
Thanks for the additional information, and I agree with what you're saying.  I have to admit to having forgotten about this bug report as I solved the issue by not using Shorewall.

I'll attempt to resolve/reassign this in the morning.

Have a nice bugday... ;)
Comment 7 Tom Wesley 2004-08-11 13:09:44 UTC
Created attachment 37242 [details]
Not workiong output of iptables -L generated by shorewall
Comment 8 Tom Wesley 2004-08-11 13:10:11 UTC
Created attachment 37243 [details]
working version created by firestarter
Comment 9 Thomas Matthijs (RETIRED) gentoo-dev 2004-08-26 11:57:32 UTC
not a java bug, and those shorewall rules look seriously broken
Comment 10 Felix Schuster 2012-07-17 11:50:38 UTC
I have had a very similar problem which was related to iptables rules, too.
Finally, I allowed the localhost (127.0.0.1) as source address to connect to localhost as destination address using the icmp protocol thus the loading time of java applets almost disappeard.