|
List Info
Thread: Re: jdk15/javaws on amd64
|
|
| Re: jdk15/javaws on amd64 |
 
Australia |
2008-03-16 17:30:54 |
On Tue Jan 1 09:11:52 PST 2008, Greg Lewis wrote:
>On Sat, Dec 29, 2007 at 11:38:01PM +1300, Jonathan Chen
wrote:
>> I'm trying out the jdk-1.5.0.13p7_1,1 javaws on
7-STABLE/amd64 system.
>> Running it with no arguments will pop-up the
web-start manager; but if
>> an jnlp file is supplied I get:
>>
>> Exception in thread "main"
java.lang.NoClassDefFoundError:
>> com/sun/deploy/util/PerfLogger
>> at com.sun.javaws.Main.main(Main.java:65
>>
>> The invocation on a 7-STABLE/i386 system appears to
work; I'm hoping
>> for tips on general whereabouts or what to look in
the source tree so
>> that I can attempt to fix the problem.
>
>That class file should be in jre/lib/deploy.jar. Thats
where it is on
>i386 at least. I don't immediately see any reason it
wouldn't be included
>on amd64.
That's an old posting but I've just run into the same issue
with
jdk-1.5.0.14p8,1 on 7-STABLE/amd64. I have confirmed that
/usr/local/jdk1.5.0/jre/lib/deploy.jar does exist and
includes
com/sun/deploy/util/PerfLogger.class - the problem seems to
be that
java has a corrupt path. The following is an extract from a
ktrace of
javaws. Note the path it uses for deploy.jar. I'm
uncertain where
this is coming from as the preceeding load of javaws.jar is
correct.
75310 java CALL stat(0x7fffffffd250,0x7fffffffd6f0)
75310 java NAMI
"/usr/local/jdk1.5.0/jre/classes"
75310 java RET stat -1 errno 2 No such file or
directory
75310 java CALL stat(0x7fffffffd250,0x7fffffffd6f0)
75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
75310 java RET stat 0
75310 java CALL lstat(0x7fffffffd1f0,0x7fffffffcc90)
75310 java NAMI "/usr"
75310 java RET lstat 0
75310 java CALL lstat(0x7fffffffd1f0,0x7fffffffcc90)
75310 java NAMI "/usr/local"
75310 java RET lstat 0
75310 java CALL lstat(0x7fffffffd1f0,0x7fffffffcc90)
75310 java NAMI "/usr/local/jdk1.5.0"
75310 java RET lstat 0
75310 java CALL lstat(0x7fffffffd1f0,0x7fffffffcc90)
75310 java NAMI "/usr/local/jdk1.5.0/jre"
75310 java RET lstat 0
75310 java CALL lstat(0x7fffffffd1f0,0x7fffffffcc90)
75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib"
75310 java RET lstat 0
75310 java CALL lstat(0x7fffffffd1f0,0x7fffffffcc90)
75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
75310 java RET lstat 0
75310 java CALL
open(0x7fffffffcba0,O_RDONLY,<unused>0)
75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
75310 java RET open 3
75310 java CALL fstat(0x3,0x7fffffffc9c0)
75310 java RET fstat 0
75310 java CALL lseek(0x3,0,SEEK_END)
75310 java RET lseek 863362/0xd2c82
75310 java CALL
mmap(0,0xd2c82,PROT_READ,MAP_SHARED,0x3,0)
75310 java RET mmap 79900672/0x804c33000
75310 java CALL close(0x3)
75310 java RET close 0
75310 java CALL stat(0x7fffffffd250,0x7fffffffd6f0)
75310 java NAMI
"<8B>H<83>[]Ã1ÀH<83>[]ÃAUATUSH<83&
gt;H<89>ýH<8B>^EÑ^M^R/deploy.jar"
75310 java RET stat -1 errno 2 No such file or
directory
75310 java CALL
mmap(0,0x3000000,PROT_NONE,MAP_PRIVATE|MAP_NORESERVE|MAP_ANO
N,0xffffffff,0)
75310 java RET mmap 80764928/0x804d06000
75310 java CALL
mmap(0x804d06000,0x270000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP
_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0)
75310 java RET mmap 80764928/0x804d06000
75310 java CALL
mmap(0,0xc0000,PROT_NONE,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,
0xffffffff,0)
75310 java RET mmap 131096576/0x807d06000
75310 java CALL
mmap(0x807d06000,0xa000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_P
RIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0)
75310 java RET mmap 131096576/0x807d06000
75310 java CALL
open(0x800b1b140,O_RDONLY,<unused>0)
75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/amd64/server/classes.jsa&q
uot;
75310 java RET open -1 errno 2 No such file or
directory
--
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.
|
|
| Re: jdk15/javaws on amd64 |
Australia |
2008-03-17 08:31:44 |
On Mon, Mar 17, 2008 at 09:30:54AM +1100, Peter Jeremy
wrote:
> On Tue Jan 1 09:11:52 PST 2008, Greg Lewis wrote:
> >On Sat, Dec 29, 2007 at 11:38:01PM +1300, Jonathan
Chen wrote:
> >> I'm trying out the jdk-1.5.0.13p7_1,1 javaws
on 7-STABLE/amd64 system.
> >> Running it with no arguments will pop-up the
web-start manager; but if
> >> an jnlp file is supplied I get:
> >>
> >> Exception in thread "main"
java.lang.NoClassDefFoundError:
> >> com/sun/deploy/util/PerfLogger
> >> at com.sun.javaws.Main.main(Main.java:65
> >>
> >> The invocation on a 7-STABLE/i386 system
appears to work; I'm hoping
> >> for tips on general whereabouts or what to
look in the source tree so
> >> that I can attempt to fix the problem.
> >
> >That class file should be in jre/lib/deploy.jar.
Thats where it is on
> >i386 at least. I don't immediately see any reason
it wouldn't be included
> >on amd64.
>
> That's an old posting but I've just run into the same
issue with
> jdk-1.5.0.14p8,1 on 7-STABLE/amd64. I have confirmed
that
> /usr/local/jdk1.5.0/jre/lib/deploy.jar does exist and
includes
> com/sun/deploy/util/PerfLogger.class - the problem
seems to be that
> java has a corrupt path. The following is an extract
from a ktrace of
> javaws. Note the path it uses for deploy.jar. I'm
uncertain where
> this is coming from as the preceeding load of
javaws.jar is correct.
>
> 75310 java CALL
stat(0x7fffffffd250,0x7fffffffd6f0)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
> 75310 java CALL
open(0x7fffffffcba0,O_RDONLY,<unused>0)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
...
> 75310 java CALL
stat(0x7fffffffd250,0x7fffffffd6f0)
> 75310 java NAMI
"<8B>H<83>[]?1?H<83>[]?AUATUSH<83&
gt;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.
--
Greg Lewis Email : glewis eyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : glewisFreeBSD.org
_______________________________________________
freebsd-javafreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to
"freebsd-java-unsubscribefreebsd.org"
|
|
| Re: jdk15/javaws on amd64 |
 
United States |
2008-03-17 11:11:47 |
On Sunday 16 March 2008 06:30 pm, Peter Jeremy wrote:
> On Tue Jan 1 09:11:52 PST 2008, Greg Lewis wrote:
> >On Sat, Dec 29, 2007 at 11:38:01PM +1300, Jonathan
Chen wrote:
> >> I'm trying out the jdk-1.5.0.13p7_1,1 javaws
on 7-STABLE/amd64
> >> system. Running it with no arguments will
pop-up the web-start
> >> manager; but if an jnlp file is supplied I
get:
> >>
> >> Exception in thread "main"
java.lang.NoClassDefFoundError:
> >> com/sun/deploy/util/PerfLogger
> >> at com.sun.javaws.Main.main(Main.java:65
> >>
> >> The invocation on a 7-STABLE/i386 system
appears to work; I'm
> >> hoping for tips on general whereabouts or what
to look in the
> >> source tree so that I can attempt to fix the
problem.
> >
> >That class file should be in jre/lib/deploy.jar.
Thats where it
> > is on i386 at least. I don't immediately see any
reason it
> > wouldn't be included on amd64.
>
> That's an old posting but I've just run into the same
issue with
> jdk-1.5.0.14p8,1 on 7-STABLE/amd64. I have confirmed
that
> /usr/local/jdk1.5.0/jre/lib/deploy.jar does exist and
includes
> com/sun/deploy/util/PerfLogger.class - the problem
seems to be that
> java has a corrupt path. The following is an extract
from a ktrace
> of javaws. Note the path it uses for deploy.jar. I'm
uncertain
> where this is coming from as the preceeding load of
javaws.jar is
> correct.
>
> 75310 java CALL
stat(0x7fffffffd250,0x7fffffffd6f0)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/classes"
> 75310 java RET stat -1 errno 2 No such file or
directory
> 75310 java CALL
stat(0x7fffffffd250,0x7fffffffd6f0)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
> 75310 java RET stat 0
> 75310 java CALL
lstat(0x7fffffffd1f0,0x7fffffffcc90)
> 75310 java NAMI "/usr"
> 75310 java RET lstat 0
> 75310 java CALL
lstat(0x7fffffffd1f0,0x7fffffffcc90)
> 75310 java NAMI "/usr/local"
> 75310 java RET lstat 0
> 75310 java CALL
lstat(0x7fffffffd1f0,0x7fffffffcc90)
> 75310 java NAMI "/usr/local/jdk1.5.0"
> 75310 java RET lstat 0
> 75310 java CALL
lstat(0x7fffffffd1f0,0x7fffffffcc90)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre"
> 75310 java RET lstat 0
> 75310 java CALL
lstat(0x7fffffffd1f0,0x7fffffffcc90)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib"
> 75310 java RET lstat 0
> 75310 java CALL
lstat(0x7fffffffd1f0,0x7fffffffcc90)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
> 75310 java RET lstat 0
> 75310 java CALL
open(0x7fffffffcba0,O_RDONLY,<unused>0)
> 75310 java NAMI
"/usr/local/jdk1.5.0/jre/lib/javaws.jar"
> 75310 java RET open 3
> 75310 java CALL fstat(0x3,0x7fffffffc9c0)
> 75310 java RET fstat 0
> 75310 java CALL lseek(0x3,0,SEEK_END)
> 75310 java RET lseek 863362/0xd2c82
> 75310 java CALL
mmap(0,0xd2c82,PROT_READ,MAP_SHARED,0x3,0)
> 75310 java RET mmap 79900672/0x804c33000
> 75310 java CALL close(0x3)
> 75310 java RET close 0
> 75310 java CALL
stat(0x7fffffffd250,0x7fffffffd6f0)
> 75310 java NAMI
>
"<8B>H<83>[]�1�H<83>[]�AUATUSH&
lt;83>H<89>�H<8B>^E�^M^R/deploy.jar"
> 75310 java RET stat -1 errno 2 No such file or
directory
> 75310 java CALL
>
mmap(0,0x3000000,PROT_NONE,MAP_PRIVATE|MAP_NORESERVE|MAP_ANO
N,0xfff
>fffff,0) 75310 java RET mmap 80764928/0x804d06000
> 75310 java CALL
>
mmap(0x804d06000,0x270000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP
_PRIVAT
>E|MAP_FIXED|MAP_ANON,0xffffffff,0) 75310 java RET
mmap
> 80764928/0x804d06000
> 75310 java CALL
>
mmap(0,0xc0000,PROT_NONE,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,
0xfffff
>fff,0) 75310 java RET mmap 131096576/0x807d06000
> 75310 java CALL
>
mmap(0x807d06000,0xa000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_P
RIVATE|
>MAP_FIXED|MAP_ANON,0xffffffff,0) 75310 java RET
mmap
> 131096576/0x807d06000
> 75310 java CALL
open(0x800b1b140,O_RDONLY,<unused>0)
> 75310 java NAMI
>
"/usr/local/jdk1.5.0/jre/lib/amd64/server/classes.jsa&q
uot; 75310 java
> RET open -1 errno 2 No such file or directory
Can you remove ~/.java and retry?
Jung-uk Kim
_______________________________________________
freebsd-javafreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to
"freebsd-java-unsubscribefreebsd.org"
|
|
| Re: jdk15/javaws on amd64 |
Australia |
2008-03-18 00:52:04 |
On Mon, Mar 17, 2008 at 12:11:47PM -0400, Jung-uk Kim
wrote:
>Can you remove ~/.java and retry?
No change.
--
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.
|
|
| Re: jdk15/javaws on amd64 |
Australia |
2008-03-18 01:15:25 |
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&
gt;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-amd6
4/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.
Out of interest, why isn't jdk15 being built using the
default CFLAGS?
--
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.
|
|
| Re: jdk15/javaws on amd64 |
Australia |
2008-03-18 16:41:06 |
On Tue, Mar 18, 2008 at 05:15:25PM +1100, Peter Jeremy
wrote:
>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;
>}
I've done a bit more investigating and the problem is that
sysGetJarLib() returns char*, and this is assumed by the
above code.
But there is no prototype in scope for the above code so gcc
assumes
that sysGetJarLib() returns int and passes it to sprintf as
an int.
Looking further, there is no prototype for sysGetJarLib()
anywhere in
the source code - or, for that matter many of the other
functions in
deploy/src/javaws/share/native/system.c that also return
char*.
This code can't work correctly on any platform where
sizeof(int) != sizeof(void*) so I'm not quite sure how Sun
make it
work on Sun SPARC...
I'm currently trying to rebuild Java with -Wall to see how
many of
these sorts of bugs exist. In the meantime, I would suggest
that
java is broken on any 64-bit architecture.
--
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.
|
|
| Re: jdk15/javaws on amd64 |
United States |
2008-03-18 16:48:30 |
Peter Jeremy wrote:
> On Tue, Mar 18, 2008 at 05:15:25PM +1100, Peter Jeremy
wrote:
>
>> 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;
>> }
>>
>
> I've done a bit more investigating and the problem is
that
> sysGetJarLib() returns char*, and this is assumed by
the above code.
> But there is no prototype in scope for the above code
so gcc assumes
> that sysGetJarLib() returns int and passes it to
sprintf as an int.
>
> Looking further, there is no prototype for
sysGetJarLib() anywhere in
> the source code - or, for that matter many of the other
functions in
> deploy/src/javaws/share/native/system.c that also
return char*.
>
> This code can't work correctly on any platform where
> sizeof(int) != sizeof(void*) so I'm not quite sure how
Sun make it
> work on Sun SPARC...
>
> I'm currently trying to rebuild Java with -Wall to see
how many of
> these sorts of bugs exist. In the meantime, I would
suggest that
> java is broken on any 64-bit architecture.
>
>
Diablo is also broken on AMD64 after the removal of KSE
threading in
8-current (so are the Sun Linux binaries)... thus as a
result it is not
possible to get Java working in any shapre or form on
8-current AMD64
_______________________________________________
freebsd-javafreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to
"freebsd-java-unsubscribefreebsd.org"
|
|
| Re: jdk15/javaws on amd64 |
Australia |
2008-03-19 00:57:31 |
G'day Peter,
On Wed, Mar 19, 2008 at 08:41:06AM +1100, Peter Jeremy
wrote:
> On Tue, Mar 18, 2008 at 05:15:25PM +1100, Peter Jeremy
wrote:
> >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;
> >}
>
> I've done a bit more investigating and the problem is
that
> sysGetJarLib() returns char*, and this is assumed by
the above code.
> But there is no prototype in scope for the above code
so gcc assumes
> that sysGetJarLib() returns int and passes it to
sprintf as an int.
>
> Looking further, there is no prototype for
sysGetJarLib() anywhere in
> the source code - or, for that matter many of the other
functions in
> deploy/src/javaws/share/native/system.c that also
return char*.
>
> This code can't work correctly on any platform where
> sizeof(int) != sizeof(void*) so I'm not quite sure how
Sun make it
> work on Sun SPARC...
I've had javaws work on amd64 for 1.5, so my guess would be
that earlier
versions of gcc have just been more lenient here. It wasn't
enabled for
amd64 without trying it  .
Also, its quite possible that it wasn't working on
Solaris/Sparc64 since
we're the first OS to include the browser plugin and javaws
on a 64 bit
platform.
> I'm currently trying to rebuild Java with -Wall to see
how many of
> these sorts of bugs exist. In the meantime, I would
suggest that
> java is broken on any 64-bit architecture.
I suspect the number is very few in the main code which is
solidly tested
on 64 bit platforms. HotSpot is compiled with -Werror and
much of the
rest of the main code is compiled with -Wall. The plugin
and javaws are
a different matter though and if there are lurking bugs of
this type they
are most likely there. As above, we're the first ones to
enable them on
amd64, so its quite possible some bugs were missed in
porting as the
plugin in particular took a lot of work to get working on a
64 bit
platform.
--
Greg Lewis Email : glewiseyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : glewisFreeBSD.org
_______________________________________________
freebsd-javafreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to
"freebsd-java-unsubscribefreebsd.org"
|
|
| Re: jdk15/javaws on amd64 |
Australia |
2008-03-19 01:00:04 |
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&
gt;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-amd6
4/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 : glewiseyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : glewisFreeBSD.org
_______________________________________________
freebsd-javafreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to
"freebsd-java-unsubscribefreebsd.org"
|
|
[1-9]
|
|