when i run eclipse-3 with ibm-jdk-1.4.2 it runs flawlessly. when i run it with sun-j2sdk-1.4.2 it gives the following error: An error has occurred. See the log file "/usr/lib/eclipse-3/configuration/1093257613502.log". and it will not start at all i have attached the log file in question. Reproducible: Always Steps to Reproduce: 1.set jdk to sun-j2sdk 2.run eclipse-3 3.error message is generated Actual Results: log file is attached Expected Results: it should work in any java 1.4.2 sdk Portage 2.0.50-r10 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r0, 2.6.8-deadmoo-r2) ================================================================= System uname: 2.6.8-deadmoo-r2 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.5.3 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/ ftp://lug.mtu.edu/gentoo/source ftp://ftp.ndlug.nd.edu/pub/gentoo/ ftp://ibiblio.org/pub/Linux/distributions/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/bmg-main" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex 3ds S3TC X X509 Xaw3d adns alsa antlr apm arts artswrappersuid asterisk async audiofile avi bcel berkdb blender-game bonobo bootsplash bsh caps cddb cdparanoia cdr cdrom chroot clamav crypt cscope cups curl dga disablekernelsupport divx4linux doc dts dvd dvdread edl encode esd evo extensions faac faad fbcon flac fluidsynth foomaticdb gd gdbm geoip gif gimpprint glade glut gnome gnomedb gnutls graphviz gstreamer gtk gtk2 gtkhtml guile idea imlib imlib2 innodb jabber jack jack-tmpfs javacomm javamail javascript jbig jdepend jikes jit joystick jpeg jsch junit jython kde kerberos krb4 ladcca latex lcms ldap leim libg++ libgda libwww live lm_sensors log4j lufsusermount lzo mad mailwrapper matroska md5sum mikmod mmx mmx2 mng monkey mozcalendar mozdevelop mozilla mozsvg mozxmlterm mpeg music mysql mythtv nas network nls nptl nvidia oav objc odbc offensive ofx oggvorbis openal opengl optional-tasks oro oss pam pcre pdflib perl pic png ppds print python qemu-fast qt quicktime quotes readline regexp remote rhino rtc ruby samba sasl scanner sdl sftplogging silc skey slang slp sndfile snmp snortsam socks5 sox speex spell sse ssl stats stencil-buffer svg tcltk tcpd tetex tga theora threads tiff truetype usb v4l v4l2 vim-with-x wmf wxwindows x86 xalan xchatdccserver xerces xface xine xml xml2 xmms xosd xprint xv xvid xvmc yv12 zlib"
Created attachment 38013 [details] the error log referenced by the error
The sun j2sdk is extremely flakey, and due to licensing restrictions, I am not allowed to install it on my own machine to test. Handing this over to Thomas for closer inspection.
Googling around I found out that there are other Gentoo users with this issue. Apparently, it is related to the fact that, when building the sun-j2sdk-1.4.2 from source, the ebuild appends a "-gentoo" to the java apps version (see 'java -version'), and eclipse doesn't like that. As a workaround, you can start eclipse anyway by following its own suggestion, i.e. disabling file locking. start it with "eclipse -vmargs -Dosgi.locking=none"...
Note: this is also true is you run the precompiled version of eclipse (not the ebuild-generated one). Ah, I only tried the gtk flavour...
can you provide links to that information? i do not believe that is the problem i have it working fine with locking using eclipse-3 -vmargs -Dosgi.locking=java.io using nio fails eclipse-3 -vmargs -Dosgi.locking=java.nio and using "none" works too offcourse
Uh, you are right, passing '-vmargs -Dosgi.locking=java.io' works (and java.nio fails)...
Given the questionable status of j2sdk in general, and its strange licensing restrictions, I don't see the value of spending our resources solving this particular problem when a semi-suitable workaround has been found. If you want to use the Sun JDK, try dev-java/sun-jdk. If you strongly disagree, reopen the bug with a good reason, and I'll certainly reconsider.
The bug is not specific to Eclipse, but makes the FileChannel.tryLock method fail in general. The problem is that in the file FileChannelImpl.c (in the source archive j2sdk-1_4_2-src-scsl.zip), the fcntl Operation F_SETLK64 is called with an Argument of type struct flock. On x86 Linux, however (at least under my kernel version 2.6.8.1), the file /usr/include/asm/fcntl.h states that F_SETLK64 must be called with an argument of type struct flock64. Presumably the three #ifdef __linux__ blocks in the file apply only to older Linux kernel versions. Unfortunately I can not currently tell whether that means kernels before 2.4 or kernels before 2.6. (I suggest reopening this bug, because it does not apply just to Eclipse, and fixing it should no longer require much "spending our resources").
Created attachment 41015 [details] Test program exhibiting the bug I have successfully patched the bug and now realise that I cannot publish the patch due to Sun's "community" source license. I suppose it is pointless then to continue to work with the source code.
Well, if you cannot publish the patch directly, maybe you can send it upstream for inclusion...
> Well, if you cannot publish the patch directly, maybe you can send it upstream for inclusion... I am trying to, but the best I have found so far is http://java.sun.com/developer/products/java2cs/ from where the relevant links all first ask one to accept the SCSL, then lead to a server error.
Argh, you are right! I always suspected that the whole java infrastructure was badly broken anyway ;-P Well, I suggest we wait a few days and try again, then bug someone at java.sun.blabla to fix their bug reporting system so that we can bug them about the bug ;-) BTW, anybody tried the new j2se 5.0 to see wether is still has the issue?
i bet there sources are for 1.4.2.0 (no new releases, as far as i can tell) and there binary is allready at 1.4.2.04
> BTW, anybody tried the new j2se 5.0 to see wether is still has the issue? The *binaries* provided by Sun do not have the problem. Only the *sources* fail when compiled on a Linux system with headers that distinguish F_SETLK and F_SETLK64 (I have linux26-headers installed). Presumably the Sun binaries are compiled on a Linux system where F_SETLK64 is still aliased to F_SETLK, hence they call F_SETLK consistently and the bug does not occur. So the most interesting release will be the J2SE 5.0 *sources*: first, to see whether they still have the bug, and second, to see whether Sun provides them under a less constricing license that offers a way to do something constructive with patches like mine. And the derelict state of Sun's "Community Source Developers Area" (latest "news" is from Feb. 2001) shows that a necessary condition is unrestricted communication about bugs and patches.
