Date: Tue, 18 Mar 2008 23:00:04 -0700 From: Greg Lewis <glewis@eyesbeyond.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-java@freebsd.org Subject: Re: jdk15/javaws on amd64 Message-ID: <20080319060004.GB19887@misty.eyesbeyond.com> In-Reply-To: <20080318061525.GQ44676@server.vk2pj.dyndns.org> References: <20080316223054.GA46447@server.vk2pj.dyndns.org> <20080317133144.GA4473@misty.eyesbeyond.com> <20080318061525.GQ44676@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
G'day Peter,
On Tue, Mar 18, 2008 at 05:15:25PM +1100, Peter Jeremy wrote:
> 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/launcher.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",
> sysGetJarLib(), FILE_SEPARATOR, "javaws_g.jar",
> PATH_SEPARATOR, sysGetJarLib(), FILE_SEPARATOR, "deploy_g.jar");
> #else
> sprintf(bootclasspath, "%s%c%s%c%s%c%s",
> 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/native -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/local/include -I/usr/local/include -D_ALLBSD_SOURCE ../../src/javaws/share/native/launcher.c -c -o /home/obj/usr/ports/java/jdk15/work/control/build/bsd-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=nocona -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.
Saw your later posting about it being the prototype for sysGetjarLib.
> Out of interest, why isn't jdk15 being built using the default CFLAGS?
This isn't deliberate. Its just likely that we haven't caught all the
places compile flags are set or overridden and made sure it respects
CFLAGS.
--
Greg Lewis Email : glewis@eyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : glewis@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080319060004.GB19887>