Date: Tue, 18 Mar 2008 17:15:25 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Greg Lewis <glewis@eyesbeyond.com> Cc: freebsd-java@freebsd.org Subject: Re: jdk15/javaws on amd64 Message-ID: <20080318061525.GQ44676@server.vk2pj.dyndns.org> In-Reply-To: <20080317133144.GA4473@misty.eyesbeyond.com> References: <20080316223054.GA46447@server.vk2pj.dyndns.org> <20080317133144.GA4473@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--f+W+jCU1fRNres8c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 17, 2008 at 06:31:44AM -0700, Greg Lewis wrote:
>On Mon, Mar 17, 2008 at 09:30:54AM +1100, Peter Jeremy wrote:
>> 75310 java CALL stat(0x7fffffffd250,0x7fffffffd6f0)
>> 75310 java NAMI "<8B>H<83>[]?1?H<83>[]?AUATUSH<83>H<89>?H<8B>^E?^M=
^R/deploy.jar"
>> 75310 java RET stat -1 errno 2 No such file or directory
>
>That certainly is an interesting path for deploy.jar...
>
>The path to deploy.jar is set up in deploy/src/javaws/share/native/launche=
r.c,
>so thats probably a good place to start.
I've done some poking at it with both some printf()s and gdb and it
appears to be a gcc bug - in fact, I'm surprised it works at all...
The relevant function is GetBootClassPath():
char* GetBootClassPath(void) {
static char bootclasspath[MAXPATHLEN];
#ifdef _DEBUG
sprintf(bootclasspath, "%s%c%s%c%s%c%s",=20
sysGetJarLib(), FILE_SEPARATOR, "javaws_g.jar",
PATH_SEPARATOR, sysGetJarLib(), FILE_SEPARATOR, "deploy_g.j=
ar");
#else
sprintf(bootclasspath, "%s%c%s%c%s%c%s",=20
sysGetJarLib(), FILE_SEPARATOR, "javaws.jar",
PATH_SEPARATOR, sysGetJarLib(), FILE_SEPARATOR, "deploy.jar=
");
#endif
return bootclasspath;
}
Within the jdk build, launcher.c is compiled with:
/usr/bin/gcc -I../../src/javaws/share/native -I../../src/javaws/solaris/na=
tive -I../../src/javaws/share/native/jpeg -I/home/obj/usr/ports/java/jdk15/=
work/control/build/bsd-amd64/tmp/deploy/javaws/jawsgensrc/headers -I/usr/lo=
cal/include -I/usr/local/include -D_ALLBSD_SOURCE ../../src/javaws/share/n=
ative/launcher.c -c -o /home/obj/usr/ports/java/jdk15/work/control/build/bs=
d-amd64/tmp/deploy/javaws/jawsobj/launcher.o
The second sysGetJarLib() is passed to sprintf() as the first memory
operand (ie (%rsp)) but for reasons known best to gcc, only a 32-bit
move is used, leaving the high 32-bits alone. In my case, when
sprintf() accesses the 64-bit value it winds up with an arbitrary address
inside one of the dynamic libraries.
I've tried building a simple test using:
cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -DDMEM foo.c -o foo
and the code is compiled correctly (actually, the generated code is
basically identical except it correctly uses 64-bit moves). I'm still
investigating what has gone wrong.
Out of interest, why isn't jdk15 being built using the default CFLAGS?
--=20
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
--f+W+jCU1fRNres8c
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)
iEYEARECAAYFAkffXf0ACgkQ/opHv/APuIcKagCglYhDmgQF1VnvjvjLusLJkrrz
urYAnREoTSqiI66c3Y644BR3lHqHZF4u
=dGjN
-----END PGP SIGNATURE-----
--f+W+jCU1fRNres8c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080318061525.GQ44676>