Re: [drlvm][x86_64] test status
On Saturday 18 November 2006 00:22 Geir Magnusson Jr. wrote: > I'll throw up a wiki page on this, but here's where we are now. I > committed H-2224, which excluded stack tests on x86_64 (and LOS on windows) > > > c-unit tests : pass > > smoke : pass (now that stack related are not run...) > > kernel : > > w/ jet > > [junit] Test java.lang.ClassAnnotationsTest FAILED > [junit] Test java.lang.reflect.FieldTest FAILED > [junit] Test org.apache.harmony.lang.annotation.AllTypesTest FAILED > > > w/ opt > > [junit] Test java.lang.ClassAnnotationsTest FAILED > [junit] Test java.lang.ClassLoaderTest FAILED > [junit] Test java.lang.reflect.FieldTest FAILED > [junit] Test org.apache.harmony.lang.annotation.AllTypesTest FAILED > > w/ interpreter > > ALL PASS > > > > Why no JVMTI tests? I've excluded them so far because one single test which enables all JVMTI capabilities like field watching, method enter/exit, etc fails on assertion. It doesn't seem to be a direct JVMTI fault (some stub fails to be generated) but since I've made JVMTI tests to fail on any event this may prevent on increasing stability for other tests. I'm going to investigate the problem for JVMTI test and try to fix it. Then if it works, I'll enable them for x86_64. But this should be done carefully because JVMTI is not yet implemented for 64-bit cleanly, breakpoints and single step won't work for sure since they rely on instrumentation of JIT generated code, assembly is different on x64_64 and low level breakpoints support will have to be implemented. On interpreter support is platform independent, so maybe I'll enable the test for interpreter only when I understand what's wrong with failing assertion. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Elena Semukhina wrote: On 11/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: Elena Semukhina wrote: > On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: >> >> Elena Semukhina wrote: >> > As Gregory mentioned ThreadTest.testJoinlongint() failure he observed >> > yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204 >> > issue >> > for that. I saw this failure quite long ago but cannot reproduce it >> today >> > trying different platforms/EMs. When the test failed, it reported that >> > actual wait time is less than required. >> > >> > The spec for join() reads: "Waits at most millis milliseconds plus >> > nanosnanoseconds for this thread to die. " There is an obvious >> > misprint here: >> > there should be "at least" but not "at most" and this was mentioned in >> > >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653 >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368 >> > >> > On the other hand, in classlib ThreadTest I saw that they agree with >> > Thread.sleep(1000) duration >= 800 and join(100, 99) duration <= >> 300. >> > >> > Can the current DRLVM guarantee that it does not exit join() earlier >> than >> > expected? >> > If not, we should make the test more tolerable to timing. >> >> There is also an unstable ObjectTest.testWaitlongint which fails once in >> a while (about once in 50 - 100 runs). It also seems to wait a bit less >> than required. I think there is also a bug in the test, nanos should be >> 50, not 500. But fixing this doesn't help, test still fails on >> windows. > > > Gregory, why do you think this is a bug? nanos can be any value between 0 > and 99. Actually there is a bug in thread_native_condvar.c which Yes it can. But I think that comparison at the end of the test that "finish - start + 1 > millis" mean that it should be 1 more millisecond of waiting. To do this it was intended to wait for 500 and a half = 500.5 milliseconds, which means that nanos should be 50, not 500. Correct my if I am wrong about the original test intension. I'm not an author of the test but I think we should wait one more millisecond even if we ask to wait 500.0005 ms because a millisecond is a minimal available time unit. I expect that the time is rounded up rather than towards the nearest vlaue. Am I wrong? Well it appears that on windows assertion in the test fails once in a while. The time of waiting finish - start + 1 = 500, so it is not strictly greater than millis = 500. I didn't try to run the test multiple times after your patch to APR. I'll let you know if I get the failures again. -- Gregory
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Elena Semukhina wrote: On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: Elena Semukhina wrote: > As Gregory mentioned ThreadTest.testJoinlongint() failure he observed > yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204 > issue > for that. I saw this failure quite long ago but cannot reproduce it today > trying different platforms/EMs. When the test failed, it reported that > actual wait time is less than required. > > The spec for join() reads: "Waits at most millis milliseconds plus > nanosnanoseconds for this thread to die. " There is an obvious > misprint here: > there should be "at least" but not "at most" and this was mentioned in > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368 > > On the other hand, in classlib ThreadTest I saw that they agree with > Thread.sleep(1000) duration >= 800 and join(100, 99) duration <= 300. > > Can the current DRLVM guarantee that it does not exit join() earlier than > expected? > If not, we should make the test more tolerable to timing. There is also an unstable ObjectTest.testWaitlongint which fails once in a while (about once in 50 - 100 runs). It also seems to wait a bit less than required. I think there is also a bug in the test, nanos should be 50, not 500. But fixing this doesn't help, test still fails on windows. Gregory, why do you think this is a bug? nanos can be any value between 0 and 99. Actually there is a bug in thread_native_condvar.c which Yes it can. But I think that comparison at the end of the test that "finish - start + 1 > millis" mean that it should be 1 more millisecond of waiting. To do this it was intended to wait for 500 and a half = 500.5 milliseconds, which means that nanos should be 50, not 500. Correct my if I am wrong about the original test intension. ignores any nanos < 1000 when converting them to microseconds. The spec for Object.wait(long) reads that waiting lasts until: ... The specified amount of real time has elapsed, more or less. It does not say neither "at most" nor "at least". I think we can fix both tests so that they could wait a little bit less than it is now expected and print the values at error messages. I attached a patch to HARMONY-2204. Please take a look and commit if it is OK. Then we can see if the tests still fail. -- Gregory
Re: [drlvm][testing] failing on test compilation
Hmm no I cannot reproduce it. Did you build the VM? Does directory
build/win_ia32_msvc_debug/deploy/jre/include exist and does it contain
include files?
In jvmti.test.xml the include path is constructed like this
${build.deploy.dir}/include. So either it doesn't exist, or
build.deploy.dir has a bad value for some reason. This property is set
up in build.xml I believe. Running ant -d may help to see the value that
it has, and the compiler command line which it uses for compiling JVMTI
test.
Vladimir Ivanov wrote:
My CC report a problem in the drlvm module. Could somebody reproduce/ fix
it?
Thanks, Vladimir
[exec] compile-jvmti-tests-native:
[exec] [echo] ## Compiling JVMTI natives in:
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\vm\tests\jvmti\VMInit1
[exec][cc] 1 total files to be compiled.
[exec][cc] VMInit1.cpp
[exec][cc]
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\vm\tests\jvmti\VMInit1\VMInit1.cpp(2)
: fatal error C1083: Cannot open include file:
'jvmti.h': No such file or directory
[exec] BUILD FAILED
[exec]
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\build\make\build.xml:380:
The following error occurred while executing this line:
[exec]
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\build\make\build_component.xml:72:
The following error occurred while executing this line:
[exec]
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\build\win_ia32_msvc_debug\semis\build\targets\jvmti.test.xml:40:
The following error occurred whi
le executing this line:
[exec]
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\build\win_ia32_msvc_debug\semis\build\targets\jvmti.test.xml:46:
cl failed with return code 2
--
Gregory
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Evgueni Brevnov wrote: In other words we will observe the crash as we do now if sem_wait completes unsuccessfully for whatever reason... Well it shouldn't return an error except for signal, shouldn't it? Two possible other errors are EINVAL and EDEADLK which should never happen. Maybe we should add an assertion after it that sem_wait was successful to catch this situation quickly, and it will be a good starting point for investigation. On 11/17/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: Gregory, The code which goes after sem_wait doesn't work properly if sem_wait returns with an error code. So we need to either loop until sem_wait returns successfully or adjust the code after sem_wait to handle irregular cases. Thanks Evgueni On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Yes - that's why I was poking him to see the patch. I was going to > suggest something very similar. > > geir > > > Gregory Shimansky wrote: > > Evgueni Brevnov wrote: > >> You can look at the change here > >> http://issues.apache.org/jira/browse/HARMONY-2203 > > > > Could someone who knowns classlib native code internals better than me > > comment on this JIRA? I've added my comment from the general POV. > > > > I would change the loop to detect only signal interruption like > > > > while (sem_wait(&wakeUpASynchReporter) == -1 && errno == EINTR); > > > > Other than that I agree with the patch. I someone does not know, every > > step in gdb also interrupts sem_wait calls, so such loops are a common > > practice when using semaphores. > > > > If someone knows classlib internal logic with this asynchronous handlers > > stuff please write your opinion. > > > -- Gregory
Re: svn commit: r475971 - /incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: On Friday 17 November 2006 02:13 [EMAIL PROTECTED] wrote: Author: geirm + 65-bit linux is not supported yet :) Neither is 64 :) Anyway, could you do the same for liblcms.a/so ? It has the same problem on x86_64. Does it? I had no problem, but happy to do it... It probably depends on a distribution. On SuSE10 and on Gentoo I had to link all 3 libng, libjpeg and liblcms dynamic libs because all three static ones didn't link. And I tried them one by one, so liblcms is no better than the other two. -- Gregory
Re: svn commit: r475971 - /incubator/harmony/enhanced/classlib/trunk/make/depends.xml
On Friday 17 November 2006 02:13 [EMAIL PROTECTED] wrote:
> Author: geirm
> +
65-bit linux is not supported yet :)
Anyway, could you do the same for liblcms.a/so ? It has the same problem on
x86_64.
> +
> + + value="libpng development package not installed
> +${line.separator}See depends/libs/build/README.txt for further details.
> +${line.separator}For Debian/Ubuntu try: apt-get install libpng12-dev
> +${line.separator}For Fedora try: yum install libpng-devel" />
> +
> + +dest="depends/libs/build/png/pngconf.h"
> +message="${png.msg}" />
> + +dest="depends/libs/build/png/png.h"
> +message="${png.msg}" />
> +
> + + value="libjpeg development package not installed
> +${line.separator}See depends/libs/build/README.txt for further details.
> +${line.separator}For Debian/Ubuntu try: apt-get install libjpeg62-dev
> +${line.separator}For Fedora try: yum install libjpeg-devel" />
> +
> + +dest="depends/libs/build/jpeg/jconfig.lnx"
> +message="${jpeg.msg}" />
> + +dest="depends/libs/build/jpeg/jpeglib.h"
> +message="${jpeg.msg}" />
> + +dest="depends/libs/build/jpeg/jmorecfg.h"
> +message="${jpeg.msg}" />
> + +dest="depends/libs/build/jpeg/jerror.h"
> +message="${jpeg.msg}" />
> +
> +
> + depends="-check-unix-common"> + src="${png.home}/lib/libpng.a"
> +
> dest="depends/libs/build/png/libpng.${hy.platform}" +
> message="${png.msg}" />
> +
> + +
> dest="depends/libs/build/jpeg/libjpeg.${hy.platform}" +
>message="${jpeg.msg}" />
> +
> +
> + depends="-check-unix-common"> + src="${png.home}/lib/libpng.so"
> +
> dest="depends/libs/build/png/libpng.${hy.platform}" +
> message="${png.msg}" />
> +
> + +
> dest="depends/libs/build/jpeg/libjpeg.${hy.platform}" +
>message="${jpeg.msg}" />
> +
> +
> +
>
> value="liblcms development package not installed
> @@ -102,7 +161,7 @@
> message="${lcms.msg}" />
>
>
> - +
>
>
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Elena Semukhina wrote: As Gregory mentioned ThreadTest.testJoinlongint() failure he observed yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204 issue for that. I saw this failure quite long ago but cannot reproduce it today trying different platforms/EMs. When the test failed, it reported that actual wait time is less than required. The spec for join() reads: "Waits at most millis milliseconds plus nanosnanoseconds for this thread to die. " There is an obvious misprint here: there should be "at least" but not "at most" and this was mentioned in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368 On the other hand, in classlib ThreadTest I saw that they agree with Thread.sleep(1000) duration >= 800 and join(100, 99) duration <= 300. Can the current DRLVM guarantee that it does not exit join() earlier than expected? If not, we should make the test more tolerable to timing. There is also an unstable ObjectTest.testWaitlongint which fails once in a while (about once in 50 - 100 runs). It also seems to wait a bit less than required. I think there is also a bug in the test, nanos should be 50, not 500. But fixing this doesn't help, test still fails on windows. I checked the APR function and underlying win API functions, the System.currentTimeMillis is measured with microseconds accuracy. The Thread.join and Thread.wait end up with WaitForSingleObject function which accepts an argument in milliseconds. So I cannot understand why the wait/join time is less than required. -- Gregory
Re: [drlvm][em64t] build fails
Egor Pasko wrote: On the 0x223 day of Apache Harmony Gregory Shimansky wrote: Egor Pasko wrote: On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Gregory Shimansky wrote: -Xss is the lower stack limit, it doesn't specify the maximum stack size, doesn't it? What does "lower stack limit" mean? :) I think that it's the size of the stack, max. I thought it is a starting stack size, like -Xms for heap size. Now that I searched the web it appears that it is the maximum indeed. "0" is minimum stack size. I think all you need to do then is set the stack size : ulimit -s 8192 or something. We should probably do this before each run on linux so that things are well defined and reproducible. I think 64-bit SuSE9 is just the only weird distribution which doesn't have this limit. In 10th version they fixed this. So ulimit -s is not necessary in most cases. But harmless. And it makes the test predicable across platforms. and if the StackSize test is forked, we can make it small to make it quick... I know nothing about forking Java processes. Does it make sense? Secondly, fork() is fast regardless of the stack size (stacks are COW). I'd still like to have a recursion limit in StackTest but Rana has convinced me that no SOE shouldn't mean that test has failed. I'll patch it now. I agree that your fix is utterly bogus :) but we want to test SOE machinery, so I think that we should set the ulimit to ensure an environment in which the SOE will happen if DRLVM is working right. Therefore, we need to set things up such that not getting an SOE is indeed a failure. What a user would most likely expect on a system with no stack limit? Something like on the other systems with stack limit as in run-anywhere concept. And that would be SOE, not swapping. So, let's limit the stack by, say, 10M if not set with an option. We can implement the option later. Well if you run StackTest on RI on a machine which doesn't have any stack limit imposed by OS you'll still see SOE quite soon. So RI has a limited stack size anyway. can anything stop us from doing the same? I don't think that anything does, we just need to agree on a reasonable stack size default. On RI and BEA it seems to be different, StackTest gives pretty different results. -- Gregory
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Evgueni Brevnov wrote: You can look at the change here http://issues.apache.org/jira/browse/HARMONY-2203 Could someone who knowns classlib native code internals better than me comment on this JIRA? I've added my comment from the general POV. I would change the loop to detect only signal interruption like while (sem_wait(&wakeUpASynchReporter) == -1 && errno == EINTR); Other than that I agree with the patch. I someone does not know, every step in gdb also interrupts sem_wait calls, so such loops are a common practice when using semaphores. If someone knows classlib internal logic with this asynchronous handlers stuff please write your opinion. -- Gregory
Re: [drlvm][em64t] build fails
Egor Pasko wrote: On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Gregory Shimansky wrote: -Xss is the lower stack limit, it doesn't specify the maximum stack size, doesn't it? What does "lower stack limit" mean? :) I think that it's the size of the stack, max. I thought it is a starting stack size, like -Xms for heap size. Now that I searched the web it appears that it is the maximum indeed. "0" is minimum stack size. I think all you need to do then is set the stack size : ulimit -s 8192 or something. We should probably do this before each run on linux so that things are well defined and reproducible. I think 64-bit SuSE9 is just the only weird distribution which doesn't have this limit. In 10th version they fixed this. So ulimit -s is not necessary in most cases. But harmless. And it makes the test predicable across platforms. and if the StackSize test is forked, we can make it small to make it quick... I know nothing about forking Java processes. Does it make sense? Secondly, fork() is fast regardless of the stack size (stacks are COW). I'd still like to have a recursion limit in StackTest but Rana has convinced me that no SOE shouldn't mean that test has failed. I'll patch it now. I agree that your fix is utterly bogus :) but we want to test SOE machinery, so I think that we should set the ulimit to ensure an environment in which the SOE will happen if DRLVM is working right. Therefore, we need to set things up such that not getting an SOE is indeed a failure. What a user would most likely expect on a system with no stack limit? Something like on the other systems with stack limit as in run-anywhere concept. And that would be SOE, not swapping. So, let's limit the stack by, say, 10M if not set with an option. We can implement the option later. Well if you run StackTest on RI on a machine which doesn't have any stack limit imposed by OS you'll still see SOE quite soon. So RI has a limited stack size anyway. -- Gregory
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: I still think that this is bogus What if SOE machinery is broken? > We need to make this a predictable test. Well I don't feel strongly to either side. We can use ulimit -s in build.sh script which runs tests (maybe only in case it runs tests). Meaning you are just as happy if it's *not* a predictable test? Not very [1]. I just wanted to make this test to pass in a predictable way on "normal" distributions which do have stack limit for applications, and at least not to misbehave on distributions that don't have this default setting. The fix is still quite questionable either way. In theory an optimizing JIT may inline all of the 1000 recursions into adding 1000 to the depth with no calls to function, which will produce no SOE. I worry about two things 1. Ulimit is not a shell command, it is a bash setting. Will ulimit -s called inside of build.sh affect commands running from it, e.g. ant test? I don't want to lose SuSE server again tonight because I don't have access to its console, so it will be rebooted only in the morning :) I dunno. I'll be happy to test on a real^H^H^H^H another distro 2. What if the limit on the system is lower than 8192? Ulimit -s allows only lower than current setting in a session (otherwise any user could increase their limit to any value). So if it is set to something like 4096 the ulimit -s 8192 command will cause an error. And the test will still work, right? [1] http://article.gmane.org/gmane.comp.java.harmony.devel/18773 http://article.gmane.org/gmane.comp.java.harmony.devel/18841 -- Gregory
Re: [x86_64] problem running DRLVM
Geir Magnusson Jr. wrote: Stefano Mazzocchi wrote: Gregory Shimansky wrote: Stefano Mazzocchi wrote: I've tried to run the VM launcher and I get: [EMAIL PROTECTED] ~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] *** glibc detected *** free(): invalid pointer: 0x7fe8aff0 *** Aborted any idea? I've reproduced the crash. It is not exactly drlvm fault. It looks like harmony launcher crashes when it is ran without arguments. If you run it with some arguments it should work, at least it does work for me. yeah, it works. you mean I'm the first one to run the launcher without parameters... bizarre. On 64-bit? :) Probably. I fixed the crash at 475483. It happened because of an uninitialized variable which happened to be non-NULL on x86_64. -- Gregory
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Geir Magnusson Jr. wrote:
I still think that this is bogus
What if SOE machinery is broken?
>
We need to make this a predictable test.
Well I don't feel strongly to either side. We can use ulimit -s in
build.sh script which runs tests (maybe only in case it runs tests).
I worry about two things
1. Ulimit is not a shell command, it is a bash setting. Will ulimit -s
called inside of build.sh affect commands running from it, e.g. ant
test? I don't want to lose SuSE server again tonight because I don't
have access to its console, so it will be rebooted only in the morning :)
2. What if the limit on the system is lower than 8192? Ulimit -s allows
only lower than current setting in a session (otherwise any user could
increase their limit to any value). So if it is set to something like
4096 the ulimit -s 8192 command will cause an error.
[EMAIL PROTECTED] wrote:
Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473
URL: http://svn.apache.org/viewvc?view=rev&rev=475473
Log:
Allow the test to pass even when no SOE happens in max_depth recursions
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473
==
---
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
(original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Wed Nov 15 14:38:55 2006
@@ -29,11 +29,10 @@
public static void main(String[] args) {
try {
func();
-System.out.println("FAIL");
} catch (StackOverflowError soe) {
System.out.println("PASS : First SOE depth = " + depth +
" : " + soe);
return;
}
-System.out.println("FAIL: no SOE in " + max_depth + "
iterations");
+System.out.println("PASS: no SOE in " + max_depth + "
iterations");
}
}
--
Gregory
Re: [drlvm][em64t] build fails
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Pavel Afremov wrote: On 11/13/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: So what is the point to have a test which would pass either way? Check that it doesn't crash the VM, is it the only purpose for it? I think yes. It should check that test doesn't crash VM if stack size isn't enough. But we wouldn't know that SOE has happened or not if test passes even when SOE was not thrown. It seems like SuSE9 is the only existing distribution which doesn't limit stack size on 64-bit architectures. SuSE10 has this limit and Gentoo has it too. Should we care that this test fails on SuSE9 when it passes on all other platforms and SOE is known to be thrown? How could there be no limit to stack size?? Well there is no stack limit imposed by the OS on SuSE9. Maybe it is specific to this version because on SuSE10 there is a normal limit of 8Mb. But when I run ulimit -a on SuSE9 I see this: core file size(blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files(-n) 4096 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes(-u) 40960 virtual memory(kbytes, -v) unlimited So the stack may grow up to the virtual address range which is pretty huge on 64-bit platforms. No physical memory is enough to allocate stack this big, so the system starts swapping nonstop. Maybe OOM linux killer will kill this process after some time, maybe not. Is there a way the test framework could set this? Does DRLVM support -Xss yet? -Xss is the lower stack limit, it doesn't specify the maximum stack size, doesn't it? What does "lower stack limit" mean? :) I think that it's the size of the stack, max. I thought it is a starting stack size, like -Xms for heap size. Now that I searched the web it appears that it is the maximum indeed. I think all you need to do then is set the stack size : ulimit -s 8192 or something. We should probably do this before each run on linux so that things are well defined and reproducible. I think 64-bit SuSE9 is just the only weird distribution which doesn't have this limit. In 10th version they fixed this. So ulimit -s is not necessary in most cases. I'd still like to have a recursion limit in StackTest but Rana has convinced me that no SOE shouldn't mean that test has failed. I'll patch it now. -- Gregory
Re: [gump] Gump running on Harmony!!
On Wednesday 15 November 2006 19:27 Stefano Mazzocchi wrote: > Great news everyone, I've finally managed to get Gump running with Harmony. > > Find it at (the semipermanent URL of Geir's server) > > http://67.86.14.213:1/gump/ > > and the 'list of todos' with importance priority can be found at > > http://67.86.14.213:1/gump/project_todos.html > > The first problem is the lack of "javac" that bootstrap-ant requires. > > Do we have a solution for that? I wonder what is causing those UnsatisfiedLinkErrors at the end of the page. What's wrong with loading libhytext.so and how is it related to finding javac? -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexei Fedotov wrote:
Guys,
This is a good discussion, and let me praise Alexey for the wonderful fix.
I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?
Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?
I saw that they failed on interpreter and saw an additional failure by
ClassGeneticsTest4, but when I reverted the patch I ran the test
individually (because running kernel tests is quite a long task). I saw
exceptions output from ClassGeneticsTest4 with reverted patch and
decided that it wasn't the one to blame. I tried reverting other patches
but all of them produced the same output. Today Alexey explained to me
that exceptions output was just a verbose test output not to related to
test passed/failed status. So the answer to your question is "not very
clearly" :)
After I saw that reverting the patches doesn't help very much I decided
that regression somehow slipped earlier but wasn't noticed. The problem
with kernel tests is that they don't pass stably. Often j.l.ThreadTest
fails and j.l.RuntimeTest2 fails on XP. So I thought that negative
result of kernel tests run was assumed to be ok because
ClassGeneticsTest4 failure was not noticed since some tests which fail
often failed.
The output of kernel tests is not very good too. They run 3 times on
JET, OPT and interpreter. The last output is for interpreter, and if the
output prints PASSED it is necessary to check result for JET and OPT. I
think the tests should either after the first test run which
didn't pass (similar to how smoke tests stop tests execution), or print
a summary at the end for all 3 runs with if case any of them
didn't pass.
On 11/15/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>
> Pardon for my English - a bit sleepy already...
>
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > Err, what I found is really trivial bug. But it took quite a few time
> > to discover - seems today was not my day :(
> >
> > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > ===
> > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > @@ -281,7 +281,7 @@
> >
> > if (NULL != exception->exc_cause) {
> > tmn_suspend_disable_recursive();
> > -jthrowable exc_cause = oh_allocate_local_handle();
> > +exc_cause = oh_allocate_local_handle();
> > exc_cause->object = exception->exc_cause;
> > tmn_suspend_enable_recursive();
> > }
> >
> >
> > OK, we definitely need a regression test for this.
> >
> > 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > >> > Alexey Varlamov wrote:
> > > >> > > The guilty change is the following, which effectively
turns on
> > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > >> >
> > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> fact that
> > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > >
> > > > Gregory,
> > > >
> > > > I've just re-read my posts and couldn't find anything critique or
> > > > offending - please don't take regressions too personal. I'm
sure we
> > > > will be able to fix this one quite soon.
> > >
> > > I wasn't offended in any way. I was just thinking that you know
some
> > > secret knowledge that lazy exceptions do not work and thus enabling
> them
> > > is wrong.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>
--
Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexey Varlamov wrote:
Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(
Index: vm/vmcore/src/exception/exceptions_impl.cpp
===
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@
if (NULL != exception->exc_cause) {
tmn_suspend_disable_recursive();
-jthrowable exc_cause = oh_allocate_local_handle();
+exc_cause = oh_allocate_local_handle();
exc_cause->object = exception->exc_cause;
tmn_suspend_enable_recursive();
}
Cool. Could you please commit the fix?
OK, we definitely need a regression test for this.
2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
Alexey Varlamov wrote:
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
>> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>> > Alexey Varlamov wrote:
>> > > The guilty change is the following, which effectively turns on
>> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> >
>> > Well this is a patch from HARMONY-2018 which doesn't hide the
fact that
>> > it enables lazy exceptions. Why shouldn't we enable them?
>
> Gregory,
>
> I've just re-read my posts and couldn't find anything critique or
> offending - please don't take regressions too personal. I'm sure we
> will be able to fix this one quite soon.
I wasn't offended in any way. I was just thinking that you know some
secret knowledge that lazy exceptions do not work and thus enabling them
is wrong.
--
Gregory
--
Gregory
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Elena Semukhina wrote: I've found one more issue in the kernel ThreadTest. Filed https://issues.apache.org/jira/browse/HARMONY-2193. Alexey, please take a look! I am not an Alexey, but I assigned this JIRA to myself. The testcase seems to be working both on linux and windows, I committed the patch. On 11/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: 2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>: > On Monday 13 November 2006 15:51 Elena Semukhina wrote: > > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: > > > After H-1823 has been committed, I still see intermittent failures of > > > drlvm kernel ThreadTest. Normally this test passes but today I got > > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures. > > > There is H-1789 for the first issue but it is not reprodiced with the > > > attached test anymore. For the second test I filed H-1876 to make the > > > test more stable. The patch has been committed recently but the test > > > still may fail. I'd like someone to review the above mentioned tests to > > > be sure they are correct otherwise we need to investigate failures and > > > file JIRA's before the tests are exclued. > > > > I looked at ThreadTest again and found one more incorrectness in > > testGetStateBlocked(): it does not wait for the thread's run() method > > actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 > > and attached the patch. I ran the test more than 100 times and did not see > > a failure. > > Cool! I'd like to see this patch applied (in case it really helps) ASAP. > Alexey V, please don't hold it for long. I would really like to see all > acceptance to pass again on all platforms and then we'll maintain no > regression state. Verified and applied (at r474672). BTW, seems we are very close to 100% pass rate for classlib tests on DRLVM. The wiki status page [1] lists just few pending issues, hopefully we'll fix them all in a couple of days. [1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM -- Gregory
Re: [jira][attachments] Is it possible to mark attachments as obsolete?
Alexei Zakharov wrote: I prefer to name the updated patch "some.patch_updated" (if the name of the original patch was "some.patch"). I am always puzzled when I see two identical names in attachments. You can always click on "All" tab to see not only comments, but status and field changes, attached patches, etc. To find the correct patch among patches with the same name just use the last which was attached. 2006/11/15, Salikh Zakirov <[EMAIL PROTECTED]>: Alexey Petrenko wrote: > Is it possible to configure JIRA to let people to mark issue > attachments as obsolete? Like in Bugzilla? > This is very useful feature when issue has few iterations of the fix. Trick: upload the file with exactly the same name, then the latest one will be marked as "latest" (in mouse-over baloon), and earlier versions will be shown in gray. I use this trick for some time. However, I've seen cases when other contributors ignored "gray" color of the attachment and reviewed/tested/committed incorrect patch. So, probably, some care from the reviewers/committers is also needed. -- Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexey Varlamov wrote: 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>: 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>: > Alexey Varlamov wrote: > > The guilty change is the following, which effectively turns on > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp: > > Well this is a patch from HARMONY-2018 which doesn't hide the fact that > it enables lazy exceptions. Why shouldn't we enable them? Gregory, I've just re-read my posts and couldn't find anything critique or offending - please don't take regressions too personal. I'm sure we will be able to fix this one quite soon. I wasn't offended in any way. I was just thinking that you know some secret knowledge that lazy exceptions do not work and thus enabling them is wrong. -- Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexey Varlamov wrote:
2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
Alexey Varlamov wrote:
> The guilty change is the following, which effectively turns on
> VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
Well this is a patch from HARMONY-2018 which doesn't hide the fact that
it enables lazy exceptions. Why shouldn't we enable them?
The point is not that we should or should not enable them, rather the
fact that the regression appeared due to this change. I just tried to
localize the problem hoping it will help to resolve this regression
soon instead of reverting.
Actually if you revert the patch (I've tried) this doesn't seem to fix
the test. At least the exceptions are still there, not sure about test
PASSED status.
Verbose test output is confusing but itself does no harm. I found so
Ah this explains it. When I tried to investigate the regression I've
reverted the patch and tried the test alone. I saw exceptions and
thought that the test failed. I didn't realize that it is just an output.
far the following:
1) the test fails on this assertion (ClassGenericsTest4.java:799):
if (!(e.getCause() instanceof
java.lang.reflect.GenericSignatureFormatError)) {
fail("test_3, case 003 FAILED: GenericSignatureFormatError should
be risen.");
}
because of e.getCause() returns null. That is, lazy machinery drops
the cause of InvocationTargetException, I did not yet figured out why.
I see. If the problem appears to be hard to solve we should revert the
HARMONY-2018 patch.
2) Test report provides the following diagnostics:
java.lang.NullPointerException at
junit.framework.TestCase.runTest(TestCase.java:168). This seems to
point to the same problem: lost cause exception after reflection.
--
Gregory
Re: [general][testing] cruise control on the WinXP and SUSE linux
Vladimir Ivanov wrote: Hello everyone, I started cruise control (stored in the "buildtest" module with patch from issue 995) on the Windows XP and SUSE Linux boxes. Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD). On each platform cruise control runs (as separate projects in СС terms, all settings have default values): - build of classlib module (target: 'rebuild'); - classlib tests on J9 VM (target 'test' in the classlib module); - build of drlvm module (target: 'build'); - vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module); - classlib tests on DRL VM (target: 'test' in the classlib module with - Dtest.jre.home=drlvm); Is it OK to send my cruise control notifications to the harmony-commits list in order to notify about regressions? I suspect the notifications are not ideal but I will work on their improvement upon precedents (false alarms) and your feedback I am +1 for cruise control and notifications to harmony-commit. But I wonder about linux version choice. If it is SuSE9, then could we upgrade it to SuSE10 or install another distribution like FC5 with gcc 4.1.x? This will help a lot with compilation errors which gcc 3.3.3 on SuSE9 doesn't report. -- Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexey Varlamov wrote: The guilty change is the following, which effectively turns on VM_LAZY_EXCEPTION support in exceptions_impl.cpp: Well this is a patch from HARMONY-2018 which doesn't hide the fact that it enables lazy exceptions. Why shouldn't we enable them? Actually if you revert the patch (I've tried) this doesn't seem to fix the test. At least the exceptions are still there, not sure about test PASSED status. Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diff&rev=475029&r1=475028&r2=475029 == --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp (original) +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp Tue Nov 14 14:45:45 2006 @@ -26,6 +26,7 @@ #include "Class.h" #include "classloader.h" #include "exceptions.h" +#include "exceptions_impl.h" #include "exceptions_jit.h" #include "exceptions_type.h" #include "environment.h" So the problem most probably in exn_throw_by_class_internal() function, will look closer after lunch. 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>: Heh, this regression is more interesting than it looked at first glance: JITs give the same output with identical stack trace, but test result is PASSED. By lucky chance I have older debug build at hand (svn = r474646) and it also spills this stacktrace to system err but status is PASSED for all execution engines. Looks like smth hase changed in exceptions processing for interpreter. 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>: > Hello > > Today a kernel tests which used to pass a day ago started to fail. It is > java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM > and classlib (since some important classes like URLClassLoader, Hashtable and > TreeMap were changed recently) patches but no reversion helped. It may be a > cumulative effect of the patches now makes the test fail. > > It fails somewhere deep inside of signature parser. The problem is also that > class format parses uses antlr which makes the whole parsing quite complex. > The failure happens on a BadSignatureTemplate class which is constructed from > bytes, parsed and its method is invoked. Apparently it has a wrong signature > (surprise :) ). > > The whole purpose of the test is not clear to me more surprising is that it > works on RI (not on BEA). If someone could point to what may be wrong now > with this test I would be very grateful. > > I also wonder why there is no InvocationTargetException which should be > chained with the down the stack Exception. The test_3 method uses reflection > to invoke a method BadSignatureTemplate.test_1 which in its turn threw an > Exception in parser. Shouldn't there be an InvocationTargetException as the > result of Method.invoke? > > Where can I look at BadSignatureTemplate.java, specifically line 13 which > according to the stack called Class.getTypeParameters? > > [1] > > [EMAIL PROTECTED]: > 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources > junit.textui.TestRunner java.lang.ClassGenericsTest4 > /lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class > java.lang.Exception >at > org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420) >at antlr.TokenBuffer.fill(TokenBuffer.java:69) >at antlr.TokenBuffer.LA(TokenBuffer.java:80) >at antlr.LLkParser.LA(LLkParser.java:52) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311) >at > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__
Re: [drlvm][em64t] build fails
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Pavel Afremov wrote: On 11/13/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: So what is the point to have a test which would pass either way? Check that it doesn't crash the VM, is it the only purpose for it? I think yes. It should check that test doesn't crash VM if stack size isn't enough. But we wouldn't know that SOE has happened or not if test passes even when SOE was not thrown. It seems like SuSE9 is the only existing distribution which doesn't limit stack size on 64-bit architectures. SuSE10 has this limit and Gentoo has it too. Should we care that this test fails on SuSE9 when it passes on all other platforms and SOE is known to be thrown? How could there be no limit to stack size?? Well there is no stack limit imposed by the OS on SuSE9. Maybe it is specific to this version because on SuSE10 there is a normal limit of 8Mb. But when I run ulimit -a on SuSE9 I see this: core file size(blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files(-n) 4096 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes(-u) 40960 virtual memory(kbytes, -v) unlimited So the stack may grow up to the virtual address range which is pretty huge on 64-bit platforms. No physical memory is enough to allocate stack this big, so the system starts swapping nonstop. Maybe OOM linux killer will kill this process after some time, maybe not. Is there a way the test framework could set this? Does DRLVM support -Xss yet? -Xss is the lower stack limit, it doesn't specify the maximum stack size, doesn't it? -- Gregory
[drlvm] New regression: java.lang.ClassGenericsTest4
at org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434) at antlr.TokenBuffer.fill(TokenBuffer.java:69) at antlr.TokenBuffer.LA(TokenBuffer.java:80) at antlr.LLkParser.LA(LLkParser.java:52) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535) at org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480) at org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378) at org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38) at java.lang.Class$GACache.getTypeParameters(Class.java:1551) at java.lang.Class.getTypeParameters(Class.java:1020) at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1 (BadSignatureTemplate.java:13) at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java) at java.lang.reflect.Method.invoke(Method.java:381) at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793) at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java) at java.lang.reflect.Method.invoke(Method.java:381) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) TokenStreamException: antlr.TokenStreamException E Time: 71.596 There was 1 error: 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException -- Gregory Shimansky, Intel Middleware Products Division
Re: [x86_64] problem running DRLVM
On Wednesday 15 November 2006 02:11 Stefano Mazzocchi wrote: > Gregory Shimansky wrote: > > Stefano Mazzocchi wrote: > >> I've tried to run the VM launcher and I get: > >> > >> [EMAIL PROTECTED] > >> ~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java > >> Harmony Java launcher > >> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > >> Foundation or its licensors, as applicable. > >> java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] > >> *** glibc detected *** free(): invalid pointer: 0x7fe8aff0 *** > >> Aborted > >> > >> any idea? > > > > I've reproduced the crash. It is not exactly drlvm fault. It looks like > > harmony launcher crashes when it is ran without arguments. If you run it > > with some arguments it should work, at least it does work for me. > > yeah, it works. > > you mean I'm the first one to run the launcher without parameters... > bizarre. No, you're the first to do it on x86_64 it seems :) It has kind of started to work just recently as has suffered several periods when build was broken even on old SuSE9. The more modern installations started to build it only today. > ok, now on to trying gump :-) -- Gregory Shimansky, Intel Middleware Products Division
Re: [x86_64] problem running DRLVM
Stefano Mazzocchi wrote: I've tried to run the VM launcher and I get: [EMAIL PROTECTED] ~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] *** glibc detected *** free(): invalid pointer: 0x7fe8aff0 *** Aborted any idea? I've reproduced the crash. It is not exactly drlvm fault. It looks like harmony launcher crashes when it is ran without arguments. If you run it with some arguments it should work, at least it does work for me. -- Gregory
Re: [x86_64] builds! now onto the tests
Stefano Mazzocchi wrote: Gregory Shimansky wrote: Stefano Mazzocchi wrote: I'm happy to report that both classlib and drlvm at r474892 build on x86_64/em64t As Gregory suggested, I had to change the symlinks to from /usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the link to avoid complaining. Well Geir insists that we should know what we are linking against, so he prefers static libraries. I don't like it very much (it is contrary to Gentoo way :) which is to link against anything which is installed on the system by the user) but I can understand this POV. The problem is that on many distributions static libs are built without -fPIC and while on x86 it may still work ok, on x86_64 it definitely doesn't work. So if we decide that we should use static linking we'll have to check in prebuilt the binaries into classlib source tree just like we did with ICU (although ICU libraries are dynamic, not shared). I see no other way to do static linking. I see. I wouldn't mind that. Both libpng and libjpeg seem to have an apache-compatible license. We already fetch java binary dependencies, it's not unreasonable to have a OS/CPU-based fetching of native statically built binaries as well since they are not going to change that much anyway over time. I don't know where we can fetch static libraries built with -fPIC since no one does that. Probably this is the way configure scripts configure the flags for building static libs. We'll have to build the binaries ourself and store them somewhere (in SVN?). -- Gregory
Re: [x86_64] builds! now onto the tests
Stefano Mazzocchi wrote:
I'm happy to report that both classlib and drlvm at r474892 build on
x86_64/em64t
As Gregory suggested, I had to change the symlinks to from
/usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the
link to avoid complaining.
Well Geir insists that we should know what we are linking against, so he
prefers static libraries. I don't like it very much (it is contrary to
Gentoo way :) which is to link against anything which is installed on
the system by the user) but I can understand this POV.
The problem is that on many distributions static libs are built without
-fPIC and while on x86 it may still work ok, on x86_64 it definitely
doesn't work. So if we decide that we should use static linking we'll
have to check in prebuilt the binaries into classlib source tree just
like we did with ICU (although ICU libraries are dynamic, not shared). I
see no other way to do static linking.
It would be great if somebody could fix the build and do that
automatically (or tell me where to do it).
Now, I've tried "ant test" in classlib and I get
compile-tests:
[echo] Compiling ACCESSIBILITY tests
[javac] Compiling 8 source files to
/home/stefano/src/harmony/classlib/modules/accessibility/bin/test
[javac] Since fork is false, ignoring memoryMaximumSize setting
[javac] --
[javac] 1. ERROR in
/home/stefano/src/harmony/classlib/modules/accessibility/src/test/api/java/common/javax/accessibility/AccessibleBundleTest.java
[javac] (at line 27)
[javac] public class AccessibleBundleTest extends
BasicSwingTestCase {
[javac] ^^
[javac] The type junit.framework.TestCase cannot be resolved. It is
indirectly referenced from required .class files
[javac] --
[javac] 1 problem (1 error)
which is pretty weird since junit was already fetched.
Am I the only one seeing this?
--
Gregory
Re: [drlvm][em64t] build fails
Pavel Afremov wrote: On 11/13/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: So what is the point to have a test which would pass either way? Check that it doesn't crash the VM, is it the only purpose for it? I think yes. It should check that test doesn't crash VM if stack size isn't enough. But we wouldn't know that SOE has happened or not if test passes even when SOE was not thrown. It seems like SuSE9 is the only existing distribution which doesn't limit stack size on 64-bit architectures. SuSE10 has this limit and Gentoo has it too. Should we care that this test fails on SuSE9 when it passes on all other platforms and SOE is known to be thrown? -- Gregory
Re: [drlvm][em64t] build fails
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
I'm going to try to do this on my Gentoo at home now. It is mostly
bleeding edge up to date installation.
Now I see what you're talking about. The threading library of
classlib doesn't compile on x86_64. It fails with the same error
[exec]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.
[exec]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
x86_64/thrspinlock.o: relocation R_X86_64_PC32 against
`hythread_yield' can not be used when making a shared object;
recompile with -fPIC
[exec]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
I've found out that thrspinlock.o is compiled from an assembly code
of thrspinlock.s which was created in HARMONY-1005. It looks like
something wasn't done correctly enough. On SuSE9 it did work ok, but
not any more. Compiling assembly sources with "gcc -fpic" didn't
change anything. It looks like the code itself has to be changed.
Thanks for having identified the issue.
Do we have any idea on how to proceed?
(sorry for being pushy, but gump is waiting ;-)
I think I've found a solution. The fix for assembly code is in
HARMONY-2185. Now if I get everything working with it I'll commit the
patch.
I've committed the fix. I had to also patch drlvm to make it compile on
gcc 4.1. In depends for classlib I had to link
/usr/lib64/lib{lcms,png,jpeg}.so files because the static versions don't
work.
Now it seems to be working but many tests crash. For the most part these
tests are kernel tests running on jitrino.opt.
--
Gregory
Re: [drlvm][em64t] build fails
Stefano Mazzocchi wrote: Gregory Shimansky wrote: On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote: I'm going to try to do this on my Gentoo at home now. It is mostly bleeding edge up to date installation. Now I see what you're talking about. The threading library of classlib doesn't compile on x86_64. It fails with the same error [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value I've found out that thrspinlock.o is compiled from an assembly code of thrspinlock.s which was created in HARMONY-1005. It looks like something wasn't done correctly enough. On SuSE9 it did work ok, but not any more. Compiling assembly sources with "gcc -fpic" didn't change anything. It looks like the code itself has to be changed. Thanks for having identified the issue. Do we have any idea on how to proceed? (sorry for being pushy, but gump is waiting ;-) I think I've found a solution. The fix for assembly code is in HARMONY-2185. Now if I get everything working with it I'll commit the patch. -- Gregory
Re: [drlvm][em64t] build fails
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote: > I'm going to try to do this on my Gentoo at home now. It is mostly > bleeding edge up to date installation. Now I see what you're talking about. The threading library of classlib doesn't compile on x86_64. It fails with the same error [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value I've found out that thrspinlock.o is compiled from an assembly code of thrspinlock.s which was created in HARMONY-1005. It looks like something wasn't done correctly enough. On SuSE9 it did work ok, but not any more. Compiling assembly sources with "gcc -fpic" didn't change anything. It looks like the code itself has to be changed. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Evgueni Brevnov wrote: hmmm strange. The patch was tested on multi-processor system running SUSE9. I will check if the patch misses something. Anyway, we need to wait with the patch submission until we 100% sure how hythread_monitor_init should behave. Thanks Evgueni On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Friday 10 November 2006 17:45 Evgueni Brevnov wrote: > Hi, > > While investigating deadlock scenario which is described in > HARMONY-2006 I found out one interesting thing. It turned out that DRL > implementation of hythread_monitor_init / > hythread_monitor_init_with_name initializes and acquires a monitor. > Original spec reads: "Acquire and initialize a new monitor from the > threading library" AFAIU that doesn't mean to lock the monitor but > get it from the threading library. So the hythread_monitor_init should > not lock the monitor. > > Could somebody comment on that? It might be that semantic is different on different platforms which is probably even worse. Your patch in HARMONY-2149 breaks nearly all of acceptance tests on Linux while everything on Windows works (ok I tested on laptop with 1 processor while Linux was a HT server, sometimes it is important for threading). I've tried to investigate the problem but didn't find the end of it yet. The bug seems to be ubuntu specific (shall we maybe call this distribution buggy and move on?). I didn't reproduce it on gentoo, all tests work just fine. The bug look likes this, on tests gc.Force, gc.LOS, gc.List, gc.NPE, gc.PhantomReferenceTest, gc.WeakReferenceTest, stress.WeakHashMapTest VM segfaults. The stack looks like an infinite recursion of 4 stack frames: #0 0xb6dcb814 in null_java_reference_handler (signum=11, info=0xb71a503c, context=0xb71a50bc) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:443 #1 #2 0xb6dcc20a in get_stack_addr () at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:293 #3 0xb6dcb6cd in check_stack_overflow (info=0xb71a546c, uc=0xb71a54ec) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:399 #4 0xb6dcb900 in null_java_reference_handler (signum=11, info=0xb71a546c, context=0xb71a54ec) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:451 and so on. The stack is very long. When I run VM with -Xtrace:signals I get a very long log of messages that "NPE or SOE detected at ...". The first time address always varies, but it appears to be memcpy. The next addresses are always the same, they point to get_stack_addr function. So I tried to find out why memcpy crashes in the first place. It appears to be a struct copy called from jsig_handler hysig. The stack looks like this (if I can trust gdb on ubuntu): #0 0xb7a9b9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7ba0fa0 in jsig_handler (sig=-1215196204, siginfo=0x0, uc=0x0) at hysigunix.c:169 #2 0xb7f9ec8b in asynchSignalReporter (userData=0x0) at hysignal.c:971 #3 0xb7baa8ef in thread_start_proc (thd=0x807a8e8, p_args=0x807a8d8) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_basic.c:712 #4 0xb7bb0ed4 in dummy_worker (opaque=0x0) at threadproc/unix/thread.c:138 #5 0xb7b65341 in start_thread () from lib/tls/i686/cmov/libpthread.so.0 #6 0xb7af94ee in clone () from /lib/tls/i686/cmov/libc.so.6 In jsig_handler a struct of type sigaction is copied act = saved_sigaction[sig]; and gcc replaces this statement with a call to memcpy it seems. But the parameter sig is quite weird if you look at it. It is sig=-1215196204... Now if I could only find where and this sig happened there... I cannot find it in the depth of classlib native code this late at night. -- Gregory
Re: [drlvm][em64t] build fails
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
Gregory Shimansky wrote:
On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
Gregory,
Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
believe it'll fix the build.
Thank you for a quick fix. The build works now. Don't try to run
acceptance tests though. The StackTest is a machine killer. It eats
all of the virtual memory in a moment because it cannot find any stack
limit ("ulimit -s 8192" may be used as a workaround) and maps all of
2^48 (or whatever number of bits are configured in kernel for virtual
address space) bytes of virtual memory. After that only reset helps.
Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which
don't have a stack limit for some reason) we need to at least fix the
test so that it doesn't make OS unusable. I've modified StackTest to
check firt 10,000,000 recursions and fail is SOE is not thrown. The
patch is available in HARMONY-2175.
Gregory,
does this mean that you are able to compile harmony on your em64t
machine? if so, can you tell me what version of gcc/ld you're using? thanks
I did compile harmony on em64t. The most tricky part was to set up
depends for classlib, I think I've written about it already. The
distribution is quite old SuSE9 with gcc 3.3.3 and GNU binutils (which
include ld) 2.15.90.0.1.1 20040303 (SuSE Linux).
I'm going to try to do this on my Gentoo at home now. It is mostly
bleeding edge up to date installation.
--
Gregory
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
On Monday 13 November 2006 15:51 Elena Semukhina wrote: > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: > > After H-1823 has been committed, I still see intermittent failures of > > drlvm kernel ThreadTest. Normally this test passes but today I got > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures. > > There is H-1789 for the first issue but it is not reprodiced with the > > attached test anymore. For the second test I filed H-1876 to make the > > test more stable. The patch has been committed recently but the test > > still may fail. I'd like someone to review the above mentioned tests to > > be sure they are correct otherwise we need to investigate failures and > > file JIRA's before the tests are exclued. > > I looked at ThreadTest again and found one more incorrectness in > testGetStateBlocked(): it does not wait for the thread's run() method > actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 > and attached the patch. I ran the test more than 100 times and did not see > a failure. Cool! I'd like to see this patch applied (in case it really helps) ASAP. Alexey V, please don't hold it for long. I would really like to see all acceptance to pass again on all platforms and then we'll maintain no regression state. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
Pavel Afremov wrote: Hello I think that Stack test should print pass if no stack overflow error is happened. Test should check processing of this error but not existing of it. Optimizing compiler can do very deep recursion unrolling, and SOE can happen never in this case. So what is the point to have a test which would pass either way? Check that it doesn't crash the VM, is it the only purpose for it? -- Gregory
Re: [drlvm][em64t] build fails
Gregory Shimansky wrote:
On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
Gregory,
Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
believe it'll fix the build.
Thank you for a quick fix. The build works now. Don't try to run acceptance
tests though. The StackTest is a machine killer. It eats all of the virtual
memory in a moment because it cannot find any stack limit ("ulimit -s 8192"
may be used as a workaround) and maps all of 2^48 (or whatever number of bits
are configured in kernel for virtual address space) bytes of virtual memory.
After that only reset helps.
Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which
don't have a stack limit for some reason) we need to at least fix the
test so that it doesn't make OS unusable. I've modified StackTest to
check firt 10,000,000 recursions and fail is SOE is not thrown. The
patch is available in HARMONY-2175.
--
Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir Magnusson Jr. wrote: > Gregory Shimansky wrote: One reason would be is that I don't know ant well enough to redesign the whole stuff all together. I used the existing setup and init targets which take care of including ancontrip and cctask jars. If you ask me, I'd prefer make in the first place, ant is just too foreign to me. There is no reason to use caps, we didn't even start to discuss how we want to see drlvm build and "when WE ARE GOING TO GET RID OF IT at some point". The caps were to get your attention. I thought you had a nice way to create a standalone testbed and then hook that in. Well as I've written already, there is very much that is done in setup and init targets of drlvm build. It is checking for necessary jar files like junit, ant-contrib, cctask. Also these targets setup a lot of necessary properties. I just didn't want to duplicate all of that stuff. The fact that these targets (setup and init) also do XML transform is almost not used in jvmti tests. Yes there are 2 which are processed in XML transform, but I can remove them when necessary. I consider this dependency on current drlvm build minor. If we decide to get rid of XML processing, the changes in jvmti tests build shall be minimal. Does it sound ok to you? The time invested, well... I learned a lot since the last time I used ant. Maybe one day I'll be able to write something as impressive and unmaintainable as the current drlvm built :) Seriously, if we're going to change it, let's discuss it how we want it to look like and which tool we'll use. I vote for make (gnu version, that is gmake), even on win32 it exists in cygwin and mingw. I think that we should simply use the same tooling that we're using now in classlib. Ok let's decide that exactly we don't like in the current drlvm build. Probably I should start another thread. -- Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote: > > Ok I think I've come up with a reasonable compromise. I still used the > > whole system of converting XML and all the stuff. It does quite a lot of > > things in setup and init targets and using is convenient. I > > don't know how to untangle all of the setup and not do a lot of > > duplication in ant scripting which I am not big expert in. > > Why? Why do we want to persist with this system, when WE ARE GOING TO > GET RID OF IT at some point? One reason would be is that I don't know ant well enough to redesign the whole stuff all together. I used the existing setup and init targets which take care of including ancontrip and cctask jars. If you ask me, I'd prefer make in the first place, ant is just too foreign to me. There is no reason to use caps, we didn't even start to discuss how we want to see drlvm build and "when WE ARE GOING TO GET RID OF IT at some point". > Did you also fix the silliness of having to use annotations to exclude > tests? Please? :) No, the patch has an exclude example using and statement in patternset in its beginning. > I'm glad we have these tests, but really... I wish you hadn't invested > the time integrating it into the DRLVM build system... Even if we write a new one from scratch I want the tests right now. There were several times when JVMTI was broken since there were no tests for it at all since it is a special VM mode no one usually uses. The time invested, well... I learned a lot since the last time I used ant. Maybe one day I'll be able to write something as impressive and unmaintainable as the current drlvm built :) Seriously, if we're going to change it, let's discuss it how we want it to look like and which tool we'll use. I vote for make (gnu version, that is gmake), even on win32 it exists in cygwin and mingw. -- Gregory Shimansky, Intel Middleware Products Division
Re: svn commit: r473588 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/ port/src/lil/em64t/pim/ vmcore/include/ vmcore/src/util/em64t/base/
On Saturday 11 November 2006 04:28 Stefano Mazzocchi wrote: > [EMAIL PROTECTED] wrote: > > Author: gshimansky > > Date: Fri Nov 10 16:17:50 2006 > > New Revision: 473588 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=473588 > > Log: > > Applied HARMONY-2152 [drlvm][em64t] build is broken after 1558 have been > > committed > > > > Since x86_64 is not yet fully supported and patch touched only x86_64 > > files no tests were ran. When I tried acceptance tests on em64t server I > > effectively shut it down. > > > > > > Modified: > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag. > >h URL: > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vm > >core/include/version_svn_tag.h?view=diff&rev=473588&r1=473587&r2=473588 > > = > >= --- > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag. > >h (original) +++ > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag. > >h Fri Nov 10 16:17:50 2006 @@ -18,6 +18,6 @@ > > #ifndef _VERSION_SVN_TAG_ > > #define _VERSION_SVN_TAG_ > > > > -#define VERSION_SVN_TAG "473506" > > +#define VERSION_SVN_TAG "svn: This client is too old to work with > > working copy '.'; please get a newer Subversion client" > > uh? Ok it seems like svn version on the x86_64 server was too old for the checked out repository. Don't worry, the version file will be fixed with a next commit to VM. It looks like we should really autogenerate it and remove it from svn as was suggested in another thread. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
On Friday 10 November 2006 17:45 Evgueni Brevnov wrote: > Hi, > > While investigating deadlock scenario which is described in > HARMONY-2006 I found out one interesting thing. It turned out that DRL > implementation of hythread_monitor_init / > hythread_monitor_init_with_name initializes and acquires a monitor. > Original spec reads: "Acquire and initialize a new monitor from the > threading library" AFAIU that doesn't mean to lock the monitor but > get it from the threading library. So the hythread_monitor_init should > not lock the monitor. > > Could somebody comment on that? It might be that semantic is different on different platforms which is probably even worse. Your patch in HARMONY-2149 breaks nearly all of acceptance tests on Linux while everything on Windows works (ok I tested on laptop with 1 processor while Linux was a HT server, sometimes it is important for threading). I think we need more investigation on whether or not the monitor has to be locked in init. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
> Gregory,
>
> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
> believe it'll fix the build.
Thank you for a quick fix. The build works now. Don't try to run acceptance
tests though. The StackTest is a machine killer. It eats all of the virtual
memory in a moment because it cannot find any stack limit ("ulimit -s 8192"
may be used as a workaround) and maps all of 2^48 (or whatever number of bits
are configured in kernel for virtual address space) bytes of virtual memory.
After that only reset helps.
> On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> > > On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > > > Same for me. I saw this yesterday. It is because HARMONY-1558 has
> >
> > changed
> >
> > > Sorry about that. I looked at Stefano's error messages. They are very
> > > similar to the ones we battled a few days ago on linux 32-bit platform.
> > > Pavel Pervov can probably tell you exactly what needs to be fixed.
> >
> > I think I can figure out myself just looking at what changes in the patch
> > were
> > done to Class::managed_null and Class::name.
> >
> > There is no reason for excuses. You did a very good job with a patch that
> > big,
> > it is good enough we didn't break anything on ia32 with it :)
> >
> > > I probably need access to a Linux 64-bit machine so that build problems
> > > like this get fixed *before* committing.
> >
> > I'll try to check my commits on x86_64 too once in a while.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote: > That's an understatement. Don't feel bad. I've never seen anything > like it before. The idea of generating ant scripts on teh fly is very > unconventional. . > You don't have enough cuts and bruises from working with the DRLVM build :) Ok I think I've come up with a reasonable compromise. I still used the whole system of converting XML and all the stuff. It does quite a lot of things in setup and init targets and using is convenient. I don't know how to untangle all of the setup and not do a lot of duplication in ant scripting which I am not big expert in. But I managed to cut away the loop over components looking at how "test" target in build.xml is written. I've also converted smoke.test target to the same way because both jvmti and smoke tests are meant for a whole VM, not some component of it. This also made a weird bug go away when of smoke tests were built and run in some random subdirectory of "semis" instead of being in "vm" when they were ran separately as "build smoke.test". Tests should be in their own subdirectories (main test inclusion/exclusion loop is done over them), main Java class for application has to be equal to have package and name equal to its subdirectory. Otherwise the build system won't know what to run. Other files may have any kind of names. I wrote one simple JVMTI test to start the suite. Other tests which I've experimented with I cannot submit because I didn't write them. I think they'll appear later from JIRAs like one in HARMONY-2143 which were submitted to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get much opposition I'll commit the patch on this weekend. Don't shoot me. Writing even that much of Ant took a lot of time, beer and hair on my head. I said I am not an ant guru, didn't I? -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
On Saturday 11 November 2006 01:43 Weldon Washburn wrote: > On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > Same for me. I saw this yesterday. It is because HARMONY-1558 has changed > > Sorry about that. I looked at Stefano's error messages. They are very > similar to the ones we battled a few days ago on linux 32-bit platform. > Pavel Pervov can probably tell you exactly what needs to be fixed. I think I can figure out myself just looking at what changes in the patch were done to Class::managed_null and Class::name. There is no reason for excuses. You did a very good job with a patch that big, it is good enough we didn't break anything on ia32 with it :) > I probably need access to a Linux 64-bit machine so that build problems > like this get fixed *before* committing. I'll try to check my commits on x86_64 too once in a while. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][threading module] a question about jthread_raw_monitor_create()
On Saturday 11 November 2006 01:36 Weldon Washburn wrote: > I might be misunderstanding the code but the local variable, > "hythread_monitor_t monitor;" is used as a parameter to a call to > array_add(jvmti_monitor_table, monitor);. It seems that once > jthread_raw_monitor_create() returns, the jvmti_monitor_table will end up > with an invalid pointer. Is this correct? It looks more like monitor value which is initialized in hythread_monitor_init is passed to array_add and there it is remembered. It is not a problem that monitor is a local variable since hythread_monitor_init provides a pointer to a data allocated somewhere not on the stack. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][build] everyday SVN conflict on the version_svn_tag.h file
On Saturday 11 November 2006 01:12 Alexei Fedotov wrote: > > generate this file as part of the build process? > > +1 for autogeneration of version_svn_tag.h It is kind of autogenerated already. To get rid of conflicts I think we should remove this file from revision control. > On 11/10/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote: > > Hello everyone, > > > > When I do my morning SVN update of drlvm module I see the permanent > > conflict on the version_svn_tag.h file because this file is updated by > > build. > > > > Actually, it is not a big problem while it not breaks vm build. But it > > will be more convenient if these conflicts go out. > > > > Could we generate this file as part of the build process (it has only 4 > > strings)? May be some other solutions exists? > > > > > > > > I'm not too familiar with VM build so I'll be glad if somebody takes care > > about it :) -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
Same for me. I saw this yesterday. It is because HARMONY-1558 has changed Class interfaces but didn't change x86_64 specific files. Now that I look at the error messages, I think it is quite easy to fix the build. I'll take care of weekend. I wonder how did you get to building drlvm if classlib didn't build for you because of -fpic problem? DRLVM build always requires prebuilt classlib... On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote: > I've managed to get everything in place for a DRLVM build.. it runs for > a while and then it fails with these errors: > >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s >upport_em64t.cpp: In function ‘void* rth_get_lil_monitor_enter()’: >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s >upport_em64t.cpp:127: error: ‘managed_null’ is not a member of ‘Class’ >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s >upport_em64t.cpp: In function ‘void* rth_get_lil_monitor_exit()’: >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s >upport_em64t.cpp:265: error: ‘managed_null’ is not a member of ‘Class’ >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp >: In function ‘void JIT_execute_method_default(void*, _jmethodID*, > jvalue*, jvalue*)’: >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp >:201: error: ‘struct Class’ has no member named ‘name’ >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp >:229: error: ‘managed_null’ is not a member of ‘Class’ >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp >:326: error: ‘managed_null’ is not a member of ‘Class’ >[cc] > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp >:359: error: ‘struct Class’ has no member named ‘name’ > > Suggestions? -- Gregory Shimansky, Intel Middleware Products Division
Re: [general] what's the status of harmony support for em64?
Stefano Mazzocchi wrote: Gregory Shimansky wrote: Stefano Mazzocchi wrote: Geir Magnusson Jr. wrote: anyway, I can't build the native part of harmony/classlib doing "ant build-native" results in classlib/depends/libs/linux.x86_64 not being found. There should be prebuilt ICU binaries. You can build them yourself or you can take them from HARMONY-1678. Note, for me those libraries had libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to set up links from *34.1 to *34. Ok, I've done this. But I still get the same error [exec] cc -shared -Wl,--version-script,libhythr.exp \ [exec] -Wl,-soname=libhythr.so -o ../libhythr.so \ [exec] ../shared/thread_copyright.o x86_64/thrhelp.o x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o thrdsup.o ../shared/thrprof.o -lpthread \ [exec] -Xlinker --start-group /home/stefano/src/harmony/classlib/deploy/lib/libhypool.a /home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker --end-group \ [exec] -lc -lm -ldl [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/bin/ld: final link failed: Bad value [exec] collect2: ld returned 1 exit status [exec] make: *** [../libhythr.so] Error 1 I've also tried to change make/properties.xml into --- properties.xml (revision 472739) +++ properties.xml (working copy) @@ -116,7 +116,7 @@ - + to see if case makes any difference (and 'ant rebuild-native') but it didn't. Did the -fPIC flag appear in compilation flags of hythread sources? I think ANT files is not the correct place to set C compilation flags. They are set somewhere in depends/build/make.include and depends/build/rules.mk. -- Gregory
Re: [general] what's the status of harmony support for em64?
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib
doing "ant build-native" results in
classlib/depends/libs/linux.x86_64
not being found.
There should be prebuilt ICU binaries. You can build them yourself or
you can take them from HARMONY-1678. Note, for me those libraries had
Oops. It should be HARMONY-1676
libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to
set up links from *34.1 to *34.
If I try to make a symlink between linux.x86_64 and linux.x86_32 (no
idea what I'm doing here, just trying things out), I get
I think this is a wrong thing to do. You cannot link together code built
for different architectures. Linker should have told you that but
apparently it encountered an internal error.
Also don't use x86 versions of lib*.a for libraries in
depends/libs/build/{jpeg,lcms,png}/. That shouldn't work. You need to
find 64-bit versions on your system or build them yourself.
Yesterday I built classlib native stuff successfully (see [classlib]
Building on x86_64 thread) but it wasn't easy. Somehow lib*.a static
libraries weren't meant to be linked to shared libraries on SUSE9, so I
had to replace links in depends/libs/build/{jpeg,lcms,png}/ with links
to shared ones. It seem to have worked, but I couldn't check how well
classlib works since drlvm build on x86_64 is now broken, most likely by
HARMONY-1558.
build-native:
[exec] make: Nothing to be done for `all'.
[exec] make: Nothing to be done for `all'.
[exec] make: Nothing to be done for `all'.
[copy] Copying 1 file to
/home/stefano/src/harmony/classlib/deploy/jdk/jre/bin
[exec] cc -shared -Wl,--version-script,libhythr.exp \
[exec] -Wl,-soname=libhythr.so -o ../libhythr.so \
[exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
[exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
[exec] -lc -lm -ldl
[exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
[exec] /usr/bin/ld: final link failed: Bad value
[exec] collect2: ld returned 1 exit status
[exec] make: *** [../libhythr.so] Error 1
googling it up a little finds
http://sources.redhat.com/ml/binutils/2005-04/msg00649.html
which is a reference to a GCC bug that was apparently fixed a long
time go.
Ah btw,
[EMAIL PROTECTED] ~/src/harmony/classlib $ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
[EMAIL PROTECTED] ~/src/harmony/classlib $ ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux
[EMAIL PROTECTED] ~/src/harmony/classlib $ uname -a
Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16
01:50:50 UTC 2006 x86_64 GNU
Please, bare with my ignorance, I have *zero* knowledge on native stuff
(I moved from x86 assembly on windows to java without going thru C ;-)
No idea what to do now, please help and I can reward you with a freshly
juiced gump run :-)
--
Gregory
Re: [general] what's the status of harmony support for em64?
Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib
doing "ant build-native" results in
classlib/depends/libs/linux.x86_64
not being found.
There should be prebuilt ICU binaries. You can build them yourself or
you can take them from HARMONY-1678. Note, for me those libraries had
libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to
set up links from *34.1 to *34.
If I try to make a symlink between linux.x86_64 and linux.x86_32 (no
idea what I'm doing here, just trying things out), I get
I think this is a wrong thing to do. You cannot link together code built
for different architectures. Linker should have told you that but
apparently it encountered an internal error.
Also don't use x86 versions of lib*.a for libraries in
depends/libs/build/{jpeg,lcms,png}/. That shouldn't work. You need to
find 64-bit versions on your system or build them yourself.
Yesterday I built classlib native stuff successfully (see [classlib]
Building on x86_64 thread) but it wasn't easy. Somehow lib*.a static
libraries weren't meant to be linked to shared libraries on SUSE9, so I
had to replace links in depends/libs/build/{jpeg,lcms,png}/ with links
to shared ones. It seem to have worked, but I couldn't check how well
classlib works since drlvm build on x86_64 is now broken, most likely by
HARMONY-1558.
build-native:
[exec] make: Nothing to be done for `all'.
[exec] make: Nothing to be done for `all'.
[exec] make: Nothing to be done for `all'.
[copy] Copying 1 file to
/home/stefano/src/harmony/classlib/deploy/jdk/jre/bin
[exec] cc -shared -Wl,--version-script,libhythr.exp \
[exec] -Wl,-soname=libhythr.so -o ../libhythr.so \
[exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
[exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
[exec] -lc -lm -ldl
[exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
[exec] /usr/bin/ld: final link failed: Bad value
[exec] collect2: ld returned 1 exit status
[exec] make: *** [../libhythr.so] Error 1
googling it up a little finds
http://sources.redhat.com/ml/binutils/2005-04/msg00649.html
which is a reference to a GCC bug that was apparently fixed a long time go.
Ah btw,
[EMAIL PROTECTED] ~/src/harmony/classlib $ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
[EMAIL PROTECTED] ~/src/harmony/classlib $ ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux
[EMAIL PROTECTED] ~/src/harmony/classlib $ uname -a
Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16
01:50:50 UTC 2006 x86_64 GNU
Please, bare with my ignorance, I have *zero* knowledge on native stuff
(I moved from x86 assembly on windows to java without going thru C ;-)
No idea what to do now, please help and I can reward you with a freshly
juiced gump run :-)
--
Gregory
Re: [drlvm] release vs. debug
Well I am always testing patches in _default_ mode which debug for VM, release for JIT and whatever it is for classlib. If defaults change then it will be some other conditions. Average time to run build test is ~60 minutes. Pavel Ozhdikhin wrote: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: I can understand that the contributor may not have access to multiple platforms, but surely he can test using both debug and release builds :-) What do we gain by asking the contributor to test less? Rana On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > +1 for debug testing before submitting a patch. > > But, for pre-commit testing we should be careful saying we'll test all the > patches in debug mode. Though it imprves quality of checks, debug build is > significantly slower then release, especially when running with > interpreter > or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and it > takes about 5 times more time than release version on my laptop, The times > were as follows: > > "build test", Windows XP/ IA32: > DRLVM release: 22 min 55 sec > DRLVM debug: 99 min 23 sec > > So, may be the good choice will be to ask patch submitters to check their > patches on the debug build and, if the JIRA issue contains comments that > this check is passed, committers may test it on release build only. > > Thanks, > Pavel > > On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > Well, since the problem is repeatable :) > > > > > > Gregory Shimansky wrote: > > > Geir Magnusson Jr. wrote: > > >> > > >> > > >> Alexei Zakharov wrote: > > >>> Hi DRLVM fans, > > >>> > > >>> I encountered a rather strange problem while working on some class > > >>> library tests. At least two tests from the beans module hang (or > > >>> crash) while running on DRLVM debug builds but work fine on DRLVM > > >>> release builds. I thought that debug build is something about adding > > >>> debug symbols to VM binaries and this should not affect the > > >>> functionality. Can someone shed a light on this? > > >> > > >> I would think it's just an assertion firing... > > > > > > Actually it is more than that. In debug mode TRACE statements are > > > compiled and therefore produce executable code. There may also be some > > > bugs in compiler generating code in different modes (although this > > > usually happens for release). > > > > > > I don't know why hanging happens, but the difference in generated code > > > is actually quite big. Also assertions or any crashes go to > > > exceptions/signal handlers which may happen to loop infinitely, there > > > were bugs like this happening on the current version of sources, look > at > > > HARMONY-2018 and HADMONY-2006. > > > > > >>> This is the first > > >>> question. The second question - what we should do with such tests. > The > > >>> tests pass on the downloadable HDK and JRE snapshots as well as on > > >>> classlib + j9. What should be the commit criteria for DRLVM – i.e. > > >>> what is the *true* build? :) I think many people here currently use > > >>> snapshots to test their patches. > > >> > > >> debug :) don't sweep the problems under the rug... > > > > > > +1 -- Gregory
Re: [classlib] Building on x86_64
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Hello
Today I tried to check what happens on x86_64 and I think I've found
some issues which need discussion
1. When classlib starts its built it tries to link 3 libraries and
headers to depends/libs/build/{jpeg,lcms,png} directories. On x86_64
SuSE9 it has failed for me to find lcms and png libraries because they
happen to be in /usr/lib64. This should not be the case on Gentoo
because /usr/lib is a link to /usr/lib64, but it looks like not all
distributions follow this way. So probably searching /usr/lib64 first
should be done on x86_64.
2. I've linked liblcms.a and libpng.a in /usr/lib64 by hands but then
linker complained that they cannot be used because relocations have to
be done. I've replaced links with links to *shared* libs and it seems
to have worked ok. For some reason libjpeg.a found in /usr/lib didn't
cause the problems. But anyway, I'd like to ask a question, why do we
want static linking? Not all distributions supply static versions of
these libraries, for example I found none in Fedora 5 even on x86. Why
not switch to shared libraries?
I do think we want to use static compilation to be sure of what we're
running with.
But what if static library was not compiled with -fpic and just cannot
be linked to dynamic library of classlib? I didn't imagine the problem,
it does happen, linker complains that I need to recompile it with -fpic.
When we link against static libraries supplied by the distribution we
don't control the library as well, it was built somewhere by someone
with unknown compilation options and the version of package is not
really known. What is the difference with dynamic libraries here? What
to do with distributions which no longer supply static libraries for
needed packages?
We could of course end up checking binaries in into SVN just like we did
ICU libraries. Now that I think of it, it may be the only option because
HDK binary snapshot has to work on any linux installation, even one
which don't have lib{png,jpeg,lcms}.so installed at all.
3. ICU libraries in HARMONY-1678 had to be linked as well because
build wants libicu*.so.34 while libraries in the archives have
libicu*.so.34.1 names. Shouldn't they be added to SVN like
depends/libs/linux.x86 ones with the same names as build wants?
4. Classlib always builds to "deploy" directory. When working with
different architectures it is good when output directories for all
files including object files are different. Otherwise it is necessary
to create separate repositories for every one of them or do clean
rebuild on every switch and never forget which version of classlib is
currently built. Could we change classlib build to create object files
in directories with architecture postfix and final output to something
like "deploy-x86_64"? Also we could separate debug/release built files
in the same way.
+1
--
Gregory
[classlib] Building on x86_64
Hello
Today I tried to check what happens on x86_64 and I think I've found some
issues which need discussion
1. When classlib starts its built it tries to link 3 libraries and headers to
depends/libs/build/{jpeg,lcms,png} directories. On x86_64 SuSE9 it has failed
for me to find lcms and png libraries because they happen to be
in /usr/lib64. This should not be the case on Gentoo because /usr/lib is a
link to /usr/lib64, but it looks like not all distributions follow this way.
So probably searching /usr/lib64 first should be done on x86_64.
2. I've linked liblcms.a and libpng.a in /usr/lib64 by hands but then linker
complained that they cannot be used because relocations have to be done. I've
replaced links with links to *shared* libs and it seems to have worked ok.
For some reason libjpeg.a found in /usr/lib didn't cause the problems. But
anyway, I'd like to ask a question, why do we want static linking? Not all
distributions supply static versions of these libraries, for example I found
none in Fedora 5 even on x86. Why not switch to shared libraries?
3. ICU libraries in HARMONY-1678 had to be linked as well because build wants
libicu*.so.34 while libraries in the archives have libicu*.so.34.1 names.
Shouldn't they be added to SVN like depends/libs/linux.x86 ones with the same
names as build wants?
4. Classlib always builds to "deploy" directory. When working with different
architectures it is good when output directories for all files including
object files are different. Otherwise it is necessary to create separate
repositories for every one of them or do clean rebuild on every switch and
never forget which version of classlib is currently built. Could we change
classlib build to create object files in directories with architecture
postfix and final output to something like "deploy-x86_64"? Also we could
separate debug/release built files in the same way.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] release vs. debug
Geir Magnusson Jr. wrote: Alexei Zakharov wrote: Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? I would think it's just an assertion firing... Actually it is more than that. In debug mode TRACE statements are compiled and therefore produce executable code. There may also be some bugs in compiler generating code in different modes (although this usually happens for release). I don't know why hanging happens, but the difference in generated code is actually quite big. Also assertions or any crashes go to exceptions/signal handlers which may happen to loop infinitely, there were bugs like this happening on the current version of sources, look at HARMONY-2018 and HADMONY-2006. This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM – i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. debug :) don't sweep the problems under the rug... +1 -- Gregory
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
Weldon Washburn wrote: 1558 pass the pre-commit "build test" on my windows laptop. I have not done a post-commit clean "svn checkout", build, build test. Mostly because build test makes my laptop unusable for over an hour. It would be good if someone can double verify the windows build is OK since 1558 commit was one hundred twenty files. Don't worry, you would've known if you broke win32 by now :) I've verified the build on winxp laptop and 2003 server with HT. Tests seem to be working as before the patch. That is gc.LOS hanging on XP, some problems with threading described in HARMONY-2070 and java.lang.ThreadTest failing. -- Gregory
Re: [drlvm][testing] the DRLVM silently exit to run the classlib tests.
Pavel Pervov wrote: 3.3.3 build crashes. I'm investigating the issue. As a workaround measure, use 4.* to compile classlib and dlrvm. Did you try 4.x on SUSE too? It looks more like dynamic libraries loading problem because stack trace shows a resolution of native method Java_java_lang_VMThreadManager_notifyAll. Since the patch changed the mode which libpthread.so was linked to VM, it looks like a crash happened when loading something linked with pthreads. I don't know why dlsym crashes instead of returning an error code, maybe it is a bug somewhere in glibc or kernel on SUSE9 linux which was fixed in other distributions which are newer. Anyway I've reverted the patch. The problem should be investigated and fixed. -- Gregory
Re: [drlvm][threading][build] HARMONY-1907 commit (r472524) breaks the build on SUSE9
Thanks for spotting this. I'll check on SUSE and if reverting this patch
helps, I'll revert it. I wonder why this doesn't break on more modern
linuxes.
Egor Pasko wrote:
Guys,
after commit of HARMONY-1907 (r472524) by Gregory ..
* Good news: builds OK :)
* Bad news: I am observing HelloWorld to fall into SEGV on SUSE9
(yes, old gcc-3.3.3 again:)
788 methods compiled successfully, last are:
EM: compile start:[JET_DPGO n=782]
java/lang/FinalizerThread$FinalizerStartLock::(Ljava/lang/FinalizerThread;)V
EM: compile done:[JET_DPGO n=782: OK]
java/lang/FinalizerThread$FinalizerStartLock::(Ljava/lang/FinalizerThread;)V
EM: compile start:[JET_DPGO n=783] java/lang/Thread::setDaemon(Z)V
EM: compile done:[JET_DPGO n=783: OK] java/lang/Thread::setDaemon(Z)V
EM: compile start:[JET_DPGO n=784] java/lang/Thread::isAlive()Z
EM: compile done:[JET_DPGO n=784: OK] java/lang/Thread::isAlive()Z
EM: compile start:[JET_DPGO n=785] java/lang/Thread::start()V
EM: compile done:[JET_DPGO n=785: OK] java/lang/Thread::start()V
EM: compile start:[JET_DPGO n=786] java/lang/Object::wait()V
EM: compile done:[JET_DPGO n=786: OK] java/lang/Object::wait()V
EM: compile start:[JET_DPGO n=787] java/lang/Thread::runImpl()V
EM: compile done:[JET_DPGO n=787: OK] java/lang/Thread::runImpl()V
EM: compile start:[JET_DPGO n=788] java/lang/Object::notifyAll()V
EM: compile done:[JET_DPGO n=788: OK] java/lang/Object::notifyAll()V
most likely, threading library failed to load, because:
(gdb) bt 20
#0 0x40007de5 in do_lookup_x () from /lib/ld-linux.so.2
#1 0x400080dc in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2 0x40558f16 in do_sym () from /lib/tls/libc.so.6
#3 0x4055904a in _dl_sym () from /lib/tls/libc.so.6
#4 0x40586158 in dlsym_doit () from /lib/libdl.so.2
#5 0x4000cf86 in _dl_catch_error () from /lib/ld-linux.so.2
#6 0x40586415 in _dlerror_run () from /lib/libdl.so.2
#7 0x40586101 in dlsym () from /lib/libdl.so.2
#8 0x40c998f7 in apr_dso_sym (ressym=0x5288f0f0, handle=0x80b4530, symname=0x52a80410
"Java_java_lang_VMThreadManager_notifyAll")
at dso.c:227
#9 0x40b9665a in natives_lookup_symbol (libraries=0x84e88e8, symbol=0x52a80410
"Java_java_lang_VMThreadManager_notifyAll")
at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/util/natives_support.cpp:629
#10 0x40b96882 in natives_lookup_method (libraries=0x84e88e8, class_name=0x807b520
"java/lang/VMThreadManager",
method_name=0x807b0f0 "notifyAll", method_desc=0x807b3b0
"(Ljava/lang/Object;)I")
at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/util/natives_support.cpp:669
#11 0x40af9d80 in ClassLoader::LookupNative (this=0x8082dc0, method=0x83f62d4)
at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1330
#12 0x40afc2ad in classloader_find_native (method=0x83f62d4)
at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2061
#13 0x40b05441 in compile_prepare_native_method (method=0x83f62d4,
flags={insert_write_barriers = 0, opt_level = 8, dynamic_profile = 0})
at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:652
#14 0x40b05979 in compile_do_compilation (method=0x83f62d4,
flags={insert_write_barriers = 0, opt_level = 8, dynamic_profile = 0})
at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:771
#15 0x40b05d99 in compile_jit_a_method (method=0x83f62d4) at
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:832
If nobody has a quick idea how to fix it, I'll take a look today
--
Gregory
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Ok I see now. I was just worried that it is something wrong with files being locked undeletable. Should continuum ignore this clean warning and try once more if it happens instead of reporting build failure? Tim Ellison wrote: Gregory Shimansky wrote: I've seen the same failure of clean target several times. Does anyone know why it happens? When I run clean again, it usually succeeds. The failure is 100% reproducible, clean usually works, but sometimes finds some files which weren't deleted. We decided that 'clean' should complain if it finds derived files left in the build directory after having removed all the files it expects to be there. Usually this would be an indication that the clean target is missing some derived files in it's remove task. However, if we rename a type (as in this case) then the build will notice the old .class file with no corresponding .java file, so it artificially triggers the warning. After printing the warning the clean task removes any remaining files anyway. If you continuously see the warning then the clean target is likely wrong, if you see it as a one-off then that it is probably due to a rename. -- Gregory
[drlvm][jvmti] Heap iteration bugfix in HARMONY-2112
Salikh I've applied your patch in HARMONY-2112 but I have a question to you. There is a new condition in jvmti_capability.cpp with the following comment: // if the global capability can_tag_objects has already been enabled, // requested by this environment, but not yet posessed by this environment, // reject the request if (ti->get_global_capability(DebugUtilsTI::TI_GC_ENABLE_TAG_OBJECTS) && !posessed.can_tag_objects && capabilities_ptr->can_tag_objects) return JVMTI_ERROR_NOT_AVAILABLE; Does it mean that only one environment at a time can hold and use tag objects functionality? Is it a temporary limitation or inherent design restriction? I don't think this limitation is serious, but if it exists it is probably worth to mention it on the drlvm limitations wiki page. -- Gregory Shimansky, Intel Middleware Products Division
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Hello I've seen the same failure of clean target several times. Does anyone know why it happens? When I run clean again, it usually succeeds. The failure is 100% reproducible, clean usually works, but sometimes finds some files which weren't deleted. On Wednesday 08 November 2006 22:05 [EMAIL PROTECTED] wrote: > [exec] -clean-bin-catch-all: > [exec][delete] Deleting 1 files from > /home/hybld/continuum-working-directory/6/classlib/build/classes [exec] > [delete] Deleted 299 directories from > /home/hybld/continuum-working-directory/6/classlib/build/classes > > [exec] BUILD FAILED > [exec] > /home/hybld/continuum-working-directory/6/classlib/build.xml:123: The > following error occurred while executing this line: [exec] > /home/hybld/continuum-working-directory/6/classlib/make/build-java.xml:96: > ... > > [exec] Built files still exist after module clean targets have run. > This [exec] probably means that one or more patternsets are incomplete. > The [exec] remaining files are: > > ... > > [exec] > /home/hybld/continuum-working-directory/6/classlib/build/classes/org/apache >/harmony/luni/util/NotYetImplementedException.class > > [exec] Total time: 1 minute 53 seconds > > BUILD FAILED > /home/hybld/continuum-working-directory/6/build.xml:114: exec returned: 1 > > Total time: 1 minute 58 seconds > > *** >* > > ... -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)
On Friday 03 November 2006 19:18 Weldon Washburn wrote: > H1558 has been a big battle to get it into committable shape. I would > really like to commit it first. (In fact, Pavel and I are working on it > right now!) The patch in HARMONY-1558 is huge and often is broken by new VM commits. Shall we make a freeze on VM commits to allow this patch it? Maintaining so many code changes is probably not an easy task. I've tried to apply it today and it doesn't apply cleanly (no surprise, 5 days passed since the last update). I think some cooperation between VM committers is required to allow this patch to be finally integrated into the code. We should either agree to let it in or let it die. I support the first option. Weldon, Geir, what do you think? -- Gregory Shimansky, Intel Middleware Products Division
Re: [build] ant-contrib downloading problems
I changed links to another SF mirror at 472107. Let me know if it doesn't work. On Tuesday 07 November 2006 15:54 Dmitry Irlyanov wrote: > Good day > > > > There is a problem, arising during dependency check in vm build: > ant-contrib.zip cannot be download from > http://prdownloads.sourceforge.net/ant-contrib/ant-contrib-1.0b2-bin.zip?do >wnload&failedmirror=belnet.dl.sourceforge.net > > but download successful in the case mirror usage > > > > Output is: > > --- > > get.external: > > [get] Getting: > http://belnet.dl.sourceforge.net/sourceforge/ant-contrib/ant-contrib-1.0b2- >bin.zip > > [get] To: > /harmony/trunk/working_vm/build/pre-copied/archives/common/ANTCONTRIB/ant- > contrib.zip > > [get] Error getting > http://belnet.dl.sourceforge.net/sourceforge/ant-contrib/ant-contrib-1.0b2- >bin.zipto > /harmony/trunk/working_vm/build/pre-copied/archives/common/ANTCONTRIB/ant- > contrib.zip > > --- > > > > Should be I have changed a hyperlink and sent patch to JIRA? > ___ > With Best Regards, > Irlyanov Dmitry > Intel Corporation > Middleware Products Division -- Gregory Shimansky, Intel Middleware Products Division
Re: [DRLVM] General stability
Weldon Washburn wrote: Folks, I have spent the last two months committing patches to the VM. While we have added a ton of much needed functionality, the stability of the system has been ignored. By chance, I looked at thread synchronization design problems this week. Its very apparent that we lack the regression testing to really find threading bugs, test the fixes and test against regression. No doubt there are similar problems in other VM subsystems. "build test" is necessary but not sufficient for where we need to go. In a sense, committing code with only "build test" to prevent regression is the equivalent to flying in the fog without instrumentation. So that we can get engineers focused on stability, I am thinking of coding the JIRAs that involve new features as "later" or even "won't fix". Please feel free to comment. We also need to restart the old email threads on regression tests. For example, we need some sort of automated test script that runs Eclipse and tomcat, etc. in a deterministic fashion so that we can compare test results. It does not have to be perfect for starts, just repeatable and easy to use. Feel free to beat me to starting these threads :) In my experience on working with drlvm, stability problems are often discovered on the existing VM acceptance tests. Big applications like eclipse or tomcat with long workloads usually reveal problems like lack of class unloading unless they crash on something like threading problems. The acceptance VM tests that we have already are a good start to test stability if they are ran nonstop many times. I don't say that we shouldn't have real application workloads. I just want to say that acceptance tests already usually reveal threading problems quite well if they are ran many times, and race conditions happen in some circumstances. However at the moment we already have failing tests, some of them like gc.LOS on WinXP don't need multiple times to make them fail. There's also java.lang.ThreadTest which fails for me on Windows 2003 server SP1 and now started to fail on Linux as well. -- Gregory
Re: [drlvm] HARMONY-1635 heap iteration WAS: [general] version of GCC...
Gregory Shimansky wrote: Salikh Zakirov wrote: Gregory Shimansky wrote: I think you could use 4.1.0 in Fedora Core 5. Since patch level shouldn't really affect the C++ compilation restrictions, the same patch should break on 4.1.0 as well. Gregory, I've looked at harmony-1635.patch you've uploaded to HARMONY-1635, and I see that is based on the outdated patch from HARMONY-1635. (i.e. not the latest version: heap-iteration-optimized.patch). Ok I didn't realize which one to take. So I will upload the updated patch myself. I've checked its compilation on Fedora Core 5 (Bordeaux) with gcc 4.1.0, and it compiles okay. In this case I think it should be committed. If I get any problems with gcc 4.1.1 (which I don't have at hand right now) I'll try to resolve them myself and create an additional fix. I can confirm that gcc 4.1.1 compiled this patch without any problems. As I've written, patchlevel shouldn't matter here, and if gcc 4.1.0 worked, 4.1.1 should work as well (with very rare exceptions). I've just built VM with it without any errors. -- Gregory
Re: [drlvm] HARMONY-1635 heap iteration WAS: [general] version of GCC...
Salikh Zakirov wrote: Gregory Shimansky wrote: I think you could use 4.1.0 in Fedora Core 5. Since patch level shouldn't really affect the C++ compilation restrictions, the same patch should break on 4.1.0 as well. Gregory, I've looked at harmony-1635.patch you've uploaded to HARMONY-1635, and I see that is based on the outdated patch from HARMONY-1635. (i.e. not the latest version: heap-iteration-optimized.patch). Ok I didn't realize which one to take. So I will upload the updated patch myself. I've checked its compilation on Fedora Core 5 (Bordeaux) with gcc 4.1.0, and it compiles okay. In this case I think it should be committed. If I get any problems with gcc 4.1.1 (which I don't have at hand right now) I'll try to resolve them myself and create an additional fix. I've uploaded updated harmony-1635.patch to HARMONY-1635. Thank you. -- Gregory
Re: [drlvm][x86_64] BBP is broken on Linux/x86_64
Geir Magnusson Jr. wrote: You should be able to just put them in, ensure they don't break x86, and let the people w/ _64 systems to check This is a good idea. I promise to install everything correctly and check 64-bit patches in native environment, but today I'll follow Geir's advice. Also I don't like the idea of downgrading classlib instead of fixing the problem with its build. Gregory Shimansky wrote: Salikh Zakirov wrote: Hi, DRLVM on Linux/x86_64 has been broken for quite some time, since commit [r467997] HARMONY-1942, back-branch polling TLS offset is incorrect. Several people noticed this and came up with solutions: HARMONY-2017 Linux em64t build failed due to typeInt32 is undefined in Ia32BBPolling.cpp HARMONY-2040 fix compilation and disable bbp on linux/x86_64 HARMONY-2017 has a patch with a solution to the problem, while HARMONY-2040 provides only a workaround. I suggest to commit HARMONY-2017 and close HARMONY-2040 as duplicate. Could some committer take care of this issue? Gregory? I've closed HARMONY-2040 and is going to work on HARMONY-2017 now. It may take a while to set up everything correctly on x86_64. -- Gregory
Re: [general] version of GCC...
Geir Magnusson Jr. wrote: Basically, I want to uplift my own platform to 4.x, and then work the kinks out of that patch. I just want to know what X is. If no one says anything, I'll figure it out and declare it :) You have to choose X between 0 and 1. Either 4.0.x (which AFAIK is used in ubuntu already - 4.0.3) or 4.1.x (which are used in FC5 - 4.1.0 and Gentoo - 4.1.1). There are no later versions on gcc.gnu.org than 4.1.1. I think 4.1.x is better because it is stricter than 4.0.x when compiling C++ (see [1]). [1] http://gcc.gnu.org/gcc-4.1/changes.html Gregory Shimansky wrote: Egor Pasko wrote: On the 0x216 day of Apache Harmony Gregory Shimansky wrote: Geir Magnusson Jr. wrote: did we ever bottom out on what range of GCC we'll support? I have a patch I want to commit that is known to not compile under 4.1.1... Hmm no I don't remember such agreement. I think GCC is mostly backwards compatible, and anything that compiles on 4.1.1 should compile on previous versions. So it is better to support the latest stable. Not many people would like to install such GCC version, but someone like me could at least give warnings that the most recent version of GCC doesn't compile some code. yes, and comment JIRA accordingly (with suggested fix). This way we can support a very wide renge of GCCs constantly. I doubt I can use the latest GCC soon, so I cannot check patches constantly. I think you could use 4.1.0 in Fedora Core 5. Since patch level shouldn't really affect the C++ compilation restrictions, the same patch should break on 4.1.0 as well. Does it make sense to use something CruiseControl-ish that walks around JIRA patches and reports statistics which of them build OK? I thought of such a tool recently.. Not a task I would dream to implement though. It could be an overkill to check on all possible gcc versions on all possible distributions and all possible platforms... When someone who has some problematic platform/distribution/gcc lets us know that something doesn't compile, it is probably enough. -- Gregory
Re: [general] version of GCC...
Egor Pasko wrote: On the 0x216 day of Apache Harmony Gregory Shimansky wrote: Geir Magnusson Jr. wrote: did we ever bottom out on what range of GCC we'll support? I have a patch I want to commit that is known to not compile under 4.1.1... Hmm no I don't remember such agreement. I think GCC is mostly backwards compatible, and anything that compiles on 4.1.1 should compile on previous versions. So it is better to support the latest stable. Not many people would like to install such GCC version, but someone like me could at least give warnings that the most recent version of GCC doesn't compile some code. yes, and comment JIRA accordingly (with suggested fix). This way we can support a very wide renge of GCCs constantly. I doubt I can use the latest GCC soon, so I cannot check patches constantly. I think you could use 4.1.0 in Fedora Core 5. Since patch level shouldn't really affect the C++ compilation restrictions, the same patch should break on 4.1.0 as well. Does it make sense to use something CruiseControl-ish that walks around JIRA patches and reports statistics which of them build OK? I thought of such a tool recently.. Not a task I would dream to implement though. It could be an overkill to check on all possible gcc versions on all possible distributions and all possible platforms... When someone who has some problematic platform/distribution/gcc lets us know that something doesn't compile, it is probably enough. -- Gregory
Re: [drlvm][x86_64] BBP is broken on Linux/x86_64
Salikh Zakirov wrote: Hi, DRLVM on Linux/x86_64 has been broken for quite some time, since commit [r467997] HARMONY-1942, back-branch polling TLS offset is incorrect. Several people noticed this and came up with solutions: HARMONY-2017 Linux em64t build failed due to typeInt32 is undefined in Ia32BBPolling.cpp HARMONY-2040 fix compilation and disable bbp on linux/x86_64 HARMONY-2017 has a patch with a solution to the problem, while HARMONY-2040 provides only a workaround. I suggest to commit HARMONY-2017 and close HARMONY-2040 as duplicate. Could some committer take care of this issue? Gregory? I've closed HARMONY-2040 and is going to work on HARMONY-2017 now. It may take a while to set up everything correctly on x86_64. -- Gregory
Re: [general] version of GCC...
Geir Magnusson Jr. wrote: did we ever bottom out on what range of GCC we'll support? I have a patch I want to commit that is known to not compile under 4.1.1... Hmm no I don't remember such agreement. I think GCC is mostly backwards compatible, and anything that compiles on 4.1.1 should compile on previous versions. So it is better to support the latest stable. Not many people would like to install such GCC version, but someone like me could at least give warnings that the most recent version of GCC doesn't compile some code. -- Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Geir I actually was serious. Probably you were confused, I didn't write "build test", I wrote "build smoke.test". The first one works ok, the second doesn't. It happens because "test" (top-level test target) is handled in a different way from "smoke.test" (target just for smoke test category) target in build.xml. The "smoke.test" target just switches default processing target to "smoke.test" and runs "process_components" (which in its turn loops over all components). The "test" special handling of processing components escapes me, I don't quite understand how it works, but it seems to work correctly, without looping. I've used them both, and targetted smoke for specific use cases (opt, etc) Hmm you probably know more about VM build than I do since you've been modifying it for quite some time already. I've just started to look into the whole thing. The question I was trying to solve was, how to correctly add jvmti.test target to the build.xml so that it would run only jvmti tests but not loop over components, but when "test" target it called, jvmti tests category would be executed along with all other categories. Including "jvmti.test" target into build.xml in the same way as "smoke.test" doesn't make me happy. Right - I thought you'd start a revolt and do it outside of the "loop over test types" system we have now. Well I am not an ant guru, and the current build system definitely requires some time to understand. I've tried to copy most of the stuff from other test ant files to make my own. I think I'll file a JIRA before committing it to make it possible to discuss it. In order to keep this simple, why not just have a separate test target for now $ sh build.sh test.jvmti and we can stare at that together, and figure out how to integrate... simplest thing would be to rename the current "test" target to "test_loop" or something, and then :) Hmm good idea, why didn't I think of it myself?... :) -- Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir I actually was serious. Probably you were confused, I didn't write "build test", I wrote "build smoke.test". The first one works ok, the second doesn't. It happens because "test" (top-level test target) is handled in a different way from "smoke.test" (target just for smoke test category) target in build.xml. The "smoke.test" target just switches default processing target to "smoke.test" and runs "process_components" (which in its turn loops over all components). The "test" special handling of processing components escapes me, I don't quite understand how it works, but it seems to work correctly, without looping. The question I was trying to solve was, how to correctly add jvmti.test target to the build.xml so that it would run only jvmti tests but not loop over components, but when "test" target it called, jvmti tests category would be executed along with all other categories. Including "jvmti.test" target into build.xml in the same way as "smoke.test" doesn't make me happy. Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Why not use junit? If you mean why not use junit to loop over tests, then it is not the case. I've used junit to do this in my work. The loop which I wrote here is the loop over components in the build.xml of drlvm. If you run "build smoke.test" you'll see that the same tests are repeated several times (you have to be patient to see this). You're joking, right? I do this for ever patch commit I do. This is done because build loops over all known VM components like vmi, vmocode, gc, interpreter, etc. It is Ok for building, and it is done exactly for building, but it is not Ok for testing because repeating tests for the whole JVM for each of its components makes no sense. You're joking here too, right? How do you know if there aren't side effects among components? geir Gregory Shimansky wrote: On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote: Gregory, I observed similar quirks with paths while intergrating kernel tests into build. AFAIU the "Grand Design" is the following: there are abstracted targets and isolated component descriptors; build system iterates through all components and tries to apply given target to each component. So there are various tricks to stop it running tests multiple times a-la "recurring inclusion protection" in C headers. I do not grok how it calculates dependencies though, but it is quite easy to drive it mad and it starts doing wrong sequence of targets and picks wrong components etc. So I just snipped off that fanciful machinery and made simple subant for "kernel.test" target - see its definition in build/make/build.xml, and compare with nearby "smoke.test" one. Ok I've made it though all of the interesting ant tricks and created my own jvmti.test target. I noticed the difference of how kernel.test target is included into build.xml as compared to smoke.test or unit.test. AFAIU only "test" target does actually work to run only once and for the required number of modes (jit, interpreter). This is done with a special workaround for "test" target in build.xml, it has its own processing. But inclusion of smoke.test and unit.test in build.xml right now makes it run in a loop for all components for which tests don't have any relation to. I am still experimenting with the build, it might be I'll find a solution for individual test categories so it would be possible to run them separately from the general "test" target. -- Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir Magnusson Jr. wrote: Why not use junit? If you mean why not use junit to loop over tests, then it is not the case. I've used junit to do this in my work. The loop which I wrote here is the loop over components in the build.xml of drlvm. If you run "build smoke.test" you'll see that the same tests are repeated several times (you have to be patient to see this). This is done because build loops over all known VM components like vmi, vmocode, gc, interpreter, etc. It is Ok for building, and it is done exactly for building, but it is not Ok for testing because repeating tests for the whole JVM for each of its components makes no sense. Gregory Shimansky wrote: On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote: Gregory, I observed similar quirks with paths while intergrating kernel tests into build. AFAIU the "Grand Design" is the following: there are abstracted targets and isolated component descriptors; build system iterates through all components and tries to apply given target to each component. So there are various tricks to stop it running tests multiple times a-la "recurring inclusion protection" in C headers. I do not grok how it calculates dependencies though, but it is quite easy to drive it mad and it starts doing wrong sequence of targets and picks wrong components etc. So I just snipped off that fanciful machinery and made simple subant for "kernel.test" target - see its definition in build/make/build.xml, and compare with nearby "smoke.test" one. Ok I've made it though all of the interesting ant tricks and created my own jvmti.test target. I noticed the difference of how kernel.test target is included into build.xml as compared to smoke.test or unit.test. AFAIU only "test" target does actually work to run only once and for the required number of modes (jit, interpreter). This is done with a special workaround for "test" target in build.xml, it has its own processing. But inclusion of smoke.test and unit.test in build.xml right now makes it run in a loop for all components for which tests don't have any relation to. I am still experimenting with the build, it might be I'll find a solution for individual test categories so it would be possible to run them separately from the general "test" target. -- Gregory
Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
On Tuesday 31 October 2006 18:28 Tim Ellison wrote: > Hurray! > > [EMAIL PROTECTED] wrote: > > Author: apetrenko > > Date: Tue Oct 31 06:57:44 2006 > > New Revision: 469512 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=469512 > > Log: > > I've added myself to the list of committers. Congrants to Alexey! I've tried to do the same but apparently cannot. I got my login today, logged on people.apache.org and changed my password for subversion. So far both for standard and enhanced modules I get the same message Sendingsite/docs/contributors.html Authentication realm: <https://svn.apache.org:443> ASF Committers Password for 'gshimansky': svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/470017/incubator/harmony/standard/site/docs/contributors.html': 403 Forbidden (https://svn.apache.org) I wonder if it is just a very unlucky day to try the first commit because of some more maintenance works done to infrastructure, or should I just be patient? I tried on different machines from command line svn client, eclipse subclipse and kdesvn with the same result. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote: > Gregory, > > I observed similar quirks with paths while intergrating kernel tests > into build. AFAIU the "Grand Design" is the following: there are > abstracted targets and isolated component descriptors; build system > iterates through all components and tries to apply given target to > each component. So there are various tricks to stop it running tests > multiple times a-la "recurring inclusion protection" in C headers. > I do not grok how it calculates dependencies though, but it is quite > easy to drive it mad and it starts doing wrong sequence of targets and > picks wrong components etc. > So I just snipped off that fanciful machinery and made simple subant > for "kernel.test" target - see its definition in build/make/build.xml, > and compare with nearby "smoke.test" one. Ok I've made it though all of the interesting ant tricks and created my own jvmti.test target. I noticed the difference of how kernel.test target is included into build.xml as compared to smoke.test or unit.test. AFAIU only "test" target does actually work to run only once and for the required number of modes (jit, interpreter). This is done with a special workaround for "test" target in build.xml, it has its own processing. But inclusion of smoke.test and unit.test in build.xml right now makes it run in a loop for all components for which tests don't have any relation to. I am still experimenting with the build, it might be I'll find a solution for individual test categories so it would be possible to run them separately from the general "test" target. -- Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][IBMVME]the return value of java.exe
On Tuesday 31 October 2006 16:39 Evgueni Brevnov wrote: > My experiments show that System.exit() terminate the whole process on > RI not only running VM. Do we all agree this is how it should work? > Does this affect embedded VMs in a negative way? I think that any process that runs JVM in itself and doesn't want to be killed by its System.exit call can use SecurityManager to make it throw SecurityException. I am quite sure that's what a java applet will get if it tries to use System.exit. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: I don't want to create a huge discussion out of it like most [testing] discussions become. Just want to know your arguments to create one more tests category. Because the current frameworks are... wacky. I can't turn off smoke tests without *recompiling* the test. The c-unit test rig is kinda cool, but inappropriate. Maybe kernel could be used. Ok I see your point. I'll try to create my own tests building and running category, maybe if it is good enough we'll transfer smoke tests to it in the future. it sounds like you just want to launch a set of conventional junit tests with a special invocation of java to get the agent running, right? Hmm I didn't think of using junit before your suggestion. Now that I think of it, it can probably work for me. It appears that it is possible to pass special to task. I'll give it a try. Now that I looked at the smoke tests build more closely and found a paths problem which I don't know how to fix, I am also inclined to make my own build script to have it separated. I would at least know how it works and own this secret like someone who wrote smoke build script does. That's what I was hoping to avoid. Something conventional. JUnit or TestNG (TestNG! TestNG!), and a separate ant script invoked from main script. Hmm I am not familiar with TestNG at all. I'll try junit first. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
On Tuesday 31 October 2006 02:27 Geir Magnusson Jr. wrote: > > So I should either create a new 4th category for tests with custom build > > file, or extend one of the current categories which we have. The most > > close to what I need is probably smoke tests category. I need to add > > building native code part and add a custom command line setting > > somewhere. > > > > Or do you think I should go with completely new tests category? > > New category Hmm... I shouldn't have asked, or I wouldn't receive two different answers :) I don't want to create a huge discussion out of it like most [testing] discussions become. Just want to know your arguments to create one more tests category. Now that I looked at the smoke tests build more closely and found a paths problem which I don't know how to fix, I am also inclined to make my own build script to have it separated. I would at least know how it works and own this secret like someone who wrote smoke build script does. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
On Tuesday 31 October 2006 00:24 Fedotov, Alexei A wrote: > Gregory wrote, > > >I need is probably smoke tests category. I need to add building native > > code > > >part and add a custom command line setting somewhere. > > +1 > I believe you need one or two test with a good coverage to check your > changes regularly. This is enough for acceptance testing. > > This doesn't inhibit the separate category - it would be quite useful > for thorough testing. But from my perspective this is not the first > thing to do. Now if I just could understand the Grand Design behind that huge tangle called drlvm ant build... I cannot find a place to start with. I thought eclipse ant debugging facilities may help (after I read how to build classlib from eclipse), and spent 2 hours trying to give it properties here and there to no avail, building drlvm from eclipse didn't work for me so far. Anyway, I think I've found a path bug with running smoke tests. The paths seems to be different depending on what I run "build.sh test" or "build.sh smoke.test". This is what I see when I run "build.sh smoke.test" /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -Dvm.assert_dialog=0 -classpath /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/vm/interpreter/_smoke.tests/classes StackTest If you look closely you'll see that tests are taken from vm/interpreter/_smoke.tests/classes while the correct location which is built when I run "build.sh test" is vm/_smoke.tests/classes. There is no interpreter path in it. If someone knows how to fix it, I'd be grateful. Now that I've tried it a second time after a full rebuild the path looks like this /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -Dvm.assert_dialog=0 -classpath /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/vm/gc_gen/_smoke.tests/classes StackTest Funny how it works picking up seemingly a random subdirectory in build/lnx_ia32_gcc_debug/semis. -- Gregory Shimansky, Intel Middleware Products Division
[drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Hello JVMTI implementation is quite a big piece of drlvm code which doesn't have any tests that are ran regularly. This may create regressions in JVMTI implementation which won't be caught early. So I want to add several small tests for JVMTI which would cover most of the currently implemented functionality. The specific of such tests is that they have to have a custom command line, to specify -agentlib: library. They also require to build native code. They need to be run in default (JIT) mode and on interpreter. Current tests which we have for commit checks for drlvm don't have these features out of the box. Cunit tests build native code, but don't run java executable. Smoke and kernel tests don't have native code and don't have a custom command line. So I should either create a new 4th category for tests with custom build file, or extend one of the current categories which we have. The most close to what I need is probably smoke tests category. I need to add building native code part and add a custom command line setting somewhere. Or do you think I should go with completely new tests category? -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] Class unloading support
On Saturday 28 October 2006 03:47 Xiao-Feng Li wrote: > All, I think the problem now is mainly about the class unloading > design not about whether class unloading happens in server > environment. Yes, the problem is easily reproducible in client environment, eclipse is an example. It is not an eclipse bug because Java spec doesn't limit an application in creating its own class loader instances. > Class unloading is definitely a feature required in future; but with > the significance of the required modifications in JVM by this class > unloading design 2 (using Java object for Vtable), it is probably > safer to move this work into a branch at the moment until all other > components are ready for it, and after we have thorough evaluation on > it since there are still issues to be resolved or discussed. > > Or we can keep it in JIRA and keep the discussion and evaluation going > on before we decide to support the special design (Java Vtable) in > other components. > > How about it? I haven't seen any patch proposal, just the design. It seems like everyone agreed with automatic collection (#2) which I also agree with. No code was presented to evaluate or test so far. I am +1 to maintain a patch in JIRA, I'll help to test it myself. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][smoke_test] running kernel classes tests on DRLVM compiled with Intel Compiler (linux/ia32)
On Wednesday 25 October 2006 13:13 Nataly Naumova wrote: > > Could you also tell me which version of icc you are using? > > Sorry - > icc -V > Intel(R) C Compiler for 32-bit applications, Version 9.0Build > 20051020Z Package ID: l_cc_c_9.0.027 Hmm I've installed icc-9.0.32 (027 is not an option to download from Intel). The same error [cc] ld: tm_self_tls: TLS definition in ../_obj/thread_native_basic.o section .tbss mismatches non-TLS reference in ../_obj/thread_native_condvar.o [cc] ../_obj/thread_native_condvar.o: could not read symbols: Bad value appeared again. Either my setup or thread manager files have a problem. I am not sure, but I'll try to figure out what's going wrong. -- Gregory Shimansky, Intel Middleware Products Division
Re: Running ActiveMQ under Harmony!
Geir Magnusson Jr. wrote: To whom did Hiram send this? It appeared in gmane.comp.java.harmony.devel news group on gmane. I read harmony-dev though this interface. The message was posted directly from gname news account but it didn't make it thought to the email alias. Probably it was deleted as spam because it was cross-posted to gmane.comp.java.activemq.devel news group. So it was seen only in news group on gmane. Link to the top level message is here [1]. [1] http://article.gmane.org/gmane.comp.java.harmony.devel/17239 Gregory Shimansky wrote: Hiram Chirino wrote: Hey, Just wanted to let you guys know that I tried running ActiveMQ using the Harmony JVM and here are the results: Harmon: latest from tonight Platform: Linux SUSE 10 ActiveMQ: 4.0.2 RC6 Using default config it bombed with: [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin> ./activemq ACTIVEMQ_HOME: /home/chirino/Desktop/incubator-activemq-4.0.2 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: UID[-6822e1e4:10e87cde34a:-8000]:dualcoreamd:1 INFO BrokerService - ActiveMQ 4.0.2 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ WARN ManagementContext - Failed to start jmx connector: javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable [EMAIL PROTECTED] [Root exception is java.lang.ClassNotFoundException: class not found] INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] java: /home/chirino/sandbox/harmony/enhanced/drlvm/trunk/vm/vmcore/src/object/object_handles.cpp:100: void GcFrame::add_object(ManagedObject**): Assertion `__null == *p || (*p >= vm_heap_base_address() && *p < vm_heap_ceiling_address())' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin> This looks like a problem investigated in HARMONY-1560. There is no patch for it though. -- Gregory Shimansky, Intel Middleware Products Division
Re: Running ActiveMQ under Harmony!
Hiram Chirino wrote: Hey, Just wanted to let you guys know that I tried running ActiveMQ using the Harmony JVM and here are the results: Harmon: latest from tonight Platform: Linux SUSE 10 ActiveMQ: 4.0.2 RC6 Using default config it bombed with: [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin> ./activemq ACTIVEMQ_HOME: /home/chirino/Desktop/incubator-activemq-4.0.2 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: UID[-6822e1e4:10e87cde34a:-8000]:dualcoreamd:1 INFO BrokerService - ActiveMQ 4.0.2 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ WARN ManagementContext - Failed to start jmx connector: javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable [EMAIL PROTECTED] [Root exception is java.lang.ClassNotFoundException: class not found] INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] java: /home/chirino/sandbox/harmony/enhanced/drlvm/trunk/vm/vmcore/src/object/object_handles.cpp:100: void GcFrame::add_object(ManagedObject**): Assertion `__null == *p || (*p >= vm_heap_base_address() && *p < vm_heap_ceiling_address())' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin> This looks like a problem investigated in HARMONY-1560. There is no patch for it though. -- Gregory Shimansky, Intel Middleware Products Division
Re: [jira] 'Patch available' status
On Friday 27 October 2006 02:29 Geir Magnusson Jr. wrote: > Gregory Shimansky wrote: > > Strange thing is that when I *do* select Harmony project and click a > > link in the box to show the specific custom fields project, > > I have no idea what that sentence means. > > then Status > > > menu doesn't have "Patch Available" item, instead there is a "Patch > > Available" checkbox at the bottom of the search queries page. That's why > > I thought it is some custom thing made only for Harmony project. Maybe > > it is just a weirdness of JIRA interface. > > it is a custom field, but can be used by multiple projects. > > I have no clue what you are talking about above. > > can you post a URL? Ok I think I'll better post screen shots (hopefully attachment filter doesn't delete png files). URL is always the same, it is [1] and the contents of page is probably created by javascript. Step 1. Open the URL [1] and look at the "Status" menu items. Scroll to the bottom. See shot1.png. It contains "Patch Available" and "Patch Reviewed" items. You can select "Patch Available" and search for JIRAs which have this status. You'll find TOMAHAWK, MYFACES, HADOOP, GERONIMO and ADFFACES, but no HARMONY. Step 2. Now select "Harmony" in projects menu. A grey box appears with a link to refresh search fields according to the project. See shot2.png. Step 3. Now click on the link in grey box. See shot3.png. Look at the "Status" menu. It has no "Patch Available" item any more. But there is a "Patch Available" check box at the bottom. Does it answer your question? [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa (It is not a Mac, it is a MacOS-X theme on Linux) -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Gregory Shimansky wrote: 2) kernel *** java.lang.ClasssGenericsTest and *** java.lang.ClassGenericsTest4 fail because of timeout, so I increase timeout in kernel.test.xml These tests work for me on Windows. But on Linux these tests fail with lost of different exceptions: For java.lang.ClassGenericsTest: java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z java.lang.TypeNotPresentException: Type java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present For java.lang.ClassGenericsTest4: Some NPEs from unobvious sources. I've attached two test reports to this email. Anyways, it looks like timeout is not the case for these tests failures. Ok I think I've found the cause of problems with these two tests on Linux which I had yesterday. On Gentoo I have russian locale set "ru_RU.KOI8-R" while on all other Linux installations it appears there are various combinations of *.UTF-8 locales (usually "en_US.UTF-8", but I found "en_AU.UTF-8" on oner server). I experimented a bit with this stuff and found out that these tests work ok when locale is some sort of UTF-8 one, including ru_RU.UTF-8 one. The result of test run is actually affected by locale set at compilation time, not the one set at the subsequent test runs. When locale at compile time is set to *.UTF-8, then test run is successful on any locale set after it. If locale is set to something simple like "C" (!) or "ru_RU.KOI8-R" at compile time then test run fails no matter what locale is set when tests are running. I wonder what we should blame here, compiler, VM, classlib or the tests? -- Gregory Shimansky, Intel Middleware Products Division
Re: [jira] 'Patch available' status
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: It is with almost as much joy as being able to report TLP that I report that "patch available" now works. First, all thanks to David Belvins. I had been able to set the "patch available" field in the default navigator, but it never occurred to me (and JIRA never bothered to tell me) that the field had to be turned on somewhere else. (Why JIRA doesn't have a field for "attachment" is utterly beyond me) Anyway, it all works now. I've added the permission to that reporters can edit their own issues, and therefore if everyone that owns a jira could go in and set the "patch available" flag as appropriate, we'll be in good shape Real Soon Now. I thought it would be a status category [*], but a separate flag is better I think. It allows anyone, not just committers, to set this state for their JIRAs. Thank you very much! [*] When I used issue finder and didn't specify a project, it showed all possible status conditions for all apache JIRAs in the choice menu. I saw "Patch Available" there. Several projects use it. So I thought you're going to enable this status state. I did Strange thing is that when I *do* select Harmony project and click a link in the box to show the specific custom fields project, then Status menu doesn't have "Patch Available" item, instead there is a "Patch Available" checkbox at the bottom of the search queries page. That's why I thought it is some custom thing made only for Harmony project. Maybe it is just a weirdness of JIRA interface. -- Gregory Shimansky, Intel Middleware Products Division
Re: [jira] 'Patch available' status
Geir Magnusson Jr. wrote: It is with almost as much joy as being able to report TLP that I report that "patch available" now works. First, all thanks to David Belvins. I had been able to set the "patch available" field in the default navigator, but it never occurred to me (and JIRA never bothered to tell me) that the field had to be turned on somewhere else. (Why JIRA doesn't have a field for "attachment" is utterly beyond me) Anyway, it all works now. I've added the permission to that reporters can edit their own issues, and therefore if everyone that owns a jira could go in and set the "patch available" flag as appropriate, we'll be in good shape Real Soon Now. I thought it would be a status category [*], but a separate flag is better I think. It allows anyone, not just committers, to set this state for their JIRAs. Thank you very much! [*] When I used issue finder and didn't specify a project, it showed all possible status conditions for all apache JIRAs in the choice menu. I saw "Patch Available" there. Several projects use it. So I thought you're going to enable this status state. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Elena Semukhina wrote: After H-1823 has been committed, I still see intermittent failures of drlvm kernel ThreadTest. Normally this test passes but today I got ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures. There is H-1789 for the first issue but it is not reprodiced with the attached test anymore. For the second test I filed H-1876 to make the test more stable. The patch has been committed recently but the test still may fail. I'd like someone to review the above mentioned tests to be sure they are correct otherwise we need to investigate failures and file JIRA's before the tests are exclued. For me ThreadTest (testJoinlongint) always fails on win32 2003 server SP1 on P4 with HT, works ok on win32 XP and on different Linuxes. I just checked and patch from 1876 is applied, but it fixes another test case, so it is not relevant. BTW I've encountered timeout on ClassGenericsTest and ClassGenericsTest4 tests on some slower machines, so it looks like they do require increased timeout. Now I agree completely with patch which Vera attached in HARMONY-1966. -- Gregory Shimansky, Intel Middleware Products Division
Re: javac and hdk
On Thursday 26 October 2006 02:07 Matthias Wessendorf wrote: > :) > > I wanna run the Trinidad build against javac from harmony! > > :) I think you can do it already and it should probably work. If Trinidad build uses ant, just using JAVA_HOME to point to Harmony would make it the JRE which ant uses. To use eclipse compiler (which is going to be used for Harmony javac) you can use ecj3.2.jar from [1] (this jar file has to be placed in $ANT_HOME/lib/ directory). To make ant use it you can specify it in compiler="org.eclipse.jdt.core.JDTCompilerAdapter" tag of javac ant target. Correct my if I missed something. [1] http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/ecj.jar -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
On Wednesday 25 October 2006 21:05 Rana Dasgupta wrote: > The ideal way would be for acceptance tests like "build test" to always > pass and to catch and roll back the patch that breaks this invariant, > rather than to disable the tests. But I agree with Vera, it is important to > keep a running set up as acceptance tests, so disabling the well known > failures may be the only way until we fix the problems. > > I don't know that any of the tests are "unstable". These are implementation > bugs. gc.LOS is a bug in thread yielding by the apr Windows functionality. > The java.lang.ObjectTest also looks like an interpreter implementation > error. I wonder about gc.LOS, I remember there was a discussion, and I think there were patches too. But I cannot find any right now. Were there any fixes to the problem which made gc.LOS to work on WinXP? Hmm and java.lang.ObjectTest works for me both on windows and linux... -- Gregory Shimansky, Intel Middleware Products Division
Re: [announcement] Apache Board approved Apache Harmony as a Top Level Project of the ASF
On Thursday 26 October 2006 00:21 Geir Magnusson Jr. wrote: > I am happy to report that the Apache Board was willing to consider our > proposal and voted to accept it at today's board meeting. Woohoo! It actually happened in October. Your optimism was not unjustified :) > As stated in the Incubation vote, this is a necessary condition for > graduation from the Incubator. > > Therefore, upon a successful outcome of the Incubator PMC vote, we are > Apache Harmony, project of the Apache Software Foundation! > > >Congratulations to everyone! +1 :) > When the vote is complete, we'll get to work on the transition > activities, but until then, just give yourself a well-deserved pat on > the back. Do the votes made on [EMAIL PROTECTED] count or is your summary sent to [EMAIL PROTECTED] enough? -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
On Wednesday 25 October 2006 20:29 Volynets, Vera wrote: > Geir > Some tests launched by command "build test" fail. > The idea of "build test" is to run it before each commit. In this way you > can catch regressions. In order to effectively catch regressions, i.e. > tests that started to fail after some change, it's necessary to have 'build > test' pass in a stable way. One of the ways to achieve stable state is to > exclude failing tests or tests which show unstable behavior. So I analysed > statistics of test runs on win ia32 platform and made up a list of tests to > be excluded: 1) smoke > *** gc.LOS fails always on jitrino and interpreter, debug and release On windows XP. Can we exclude it only for win32 and leave it on Linux? > 2) kernel > *** java.lang.ClasssGenericsTest and > *** java.lang.ClassGenericsTest4 fail because of timeout, so I increase > timeout in kernel.test.xml These tests work for me on Windows. But on Linux these tests fail with lost of different exceptions: For java.lang.ClassGenericsTest: java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z java.lang.TypeNotPresentException: Type java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present For java.lang.ClassGenericsTest4: Some NPEs from unobvious sources. I've attached two test reports to this email. Anyways, it looks like timeout is not the case for these tests failures. > *** java.lang.ObjectTest fail on interpreter > with following message: Testsuite: java.lang.ObjectTest > Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec > Testcase: testWait1(java.lang.ObjectTest): FAILED > An InterruptedException must be thrown in test thread! > junit.framework.AssertionFailedError: An InterruptedException must be > thrown in test thread! This test works ok for me, probably after HARMONY-1823 was applied. Are you sure you run the latest sources? -- Gregory Shimansky, Intel Middleware Products Division Testsuite: java.lang.ClassGenericsTest Tests run: 8, Failures: 0, Errors: 2, Time elapsed: 1.371 sec - Standard Output --- TUuUuU;|7 T\0ce\091;|10 T\0d5\0b6\0db\080\0db\0b1;|26 T\0d5\0b6\0db\080\0db\0b13;|27 T\0d5\0b6\0db\080\0db\0b12;|27 T\0d5\0b6\0db\080\0db\0b11;|27 TUuUuU;|7 T\0ce\091;|10 T\0d5\0b6\0db\080\0db\0b1;|26 T\0d5\0b6\0db\080\0db\0b13;|27 T\0d5\0b6\0db\080\0db\0b12;|27 T\0d5\0b6\0db\080\0db\0b11;|27 - --- - Standard Error - Error: AuxiliaryLoader.findClass(java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1): java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009 java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009 at java.net.URLClassLoader.findClass(URLClassLoader.java:625) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader$SystemClassLoader.loadClass(Unknown Source) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.harmony.lang.reflect.support.AuxiliaryLoader$1.run(Unknown Source) at java.security.AccessController.doPrivilegedImpl(Unknown Source) at java.security.AccessController.doPrivileged(Unknown Source) at org.apache.harmony.lang.reflect.support.AuxiliaryLoader.findClass(Unknown Source) at java.lang.reflect.Method$MethodData.initGenericExceptionTypes(Unknown Source) at java.lang.reflect.Method.getGenericExceptionTypes(Unknown Source) at java.lang.ClassGenericsTest.test_5(ClassGenericsTest.java:655) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:128) at junit.framework.TestResult$1.protect(TestResult.java:107) at junit.framework.TestResult.runProtected(TestResult.java:135) at junit.framework.TestResult.run(TestResult.java:104) at junit.framework.TestCase.run(TestCase.java:121) at junit.framework.TestSuite.runTest(TestSuite.java:231) at junit.framework.TestSuite.run(TestSuite.java:224) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:294) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:670) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) - --- Testcase: test_2(java.lang.ClassGenericsTest): Caused an ERROR java/lang/ClassGenericsTest$Mc007 java.lang.NoClassDefFoundError: java/lang/ClassG
Re: [general] Board resolution for Apache Harmony project
On Wednesday 25 October 2006 21:53 robert burrell donkin wrote: > On 10/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > Geir Magnusson Jr. wrote: > > > any comments? any at all? > > > > I don't know the formal form of such documents. > > see links from http://www.apache.org/foundation/board/calendar.html Thanks for the link. I've read several decision reports and they look very much like Geir's proposal in form, so to it seems to be the right one. -- Gregory Shimansky, Intel Middleware Products Division
Re: [general] Board resolution for Apache Harmony project
Geir Magnusson Jr. wrote:
any comments? any at all?
I don't know the formal form of such documents. If it fits the form,
then it is ok to me because the proposal contents looks just fine.
Geir Magnusson Jr. wrote:
I've been anticipating this moment for 2 years now... :)
While it doesn't seem possible given infrastructure issues that are
interfering with mail to get something in front of the board tomorrow
(plus the fact that the board likes things in advance) if a miracle
happens I'd like to try, and if not, we need this anyway for next
month, so we should get this put to bed (and back to work).
Here's a proposed resolution to put before the board to create Apache
Harmony as a Top Level Project (TLP) of the ASF. As per a discussion
on the -private list, it's been suggested that I be offered as the
candidate to the board as the PMC chair, so I filled in that blank,
but that's open for discussion like everything else in this proposal.
(The board chooses a chair - we just make the suggestion). There's no
real rush to get this in tomorrow - as I said, it's really unlikely
anyway - so please speak up with comments or concerns.
- 0 -
Establish the Apache Harmony project
WHEREAS, the Board of Directors deems it to be in the best interests
of the Foundation and consistent with the Foundation's purpose to
establish a Project Management Committee charged with the creation and
maintenance of open-source software implementing Java virtual
machines, related class libraries, and other software that is commonly
associated with Java platforms, for distribution at no charge to the
public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Harmony PMC", be and hereby is established
pursuant to Bylaws of the Foundation; and be it further
RESOLVED, that the Harmony PMC be and hereby is responsible for the
creation and maintenance of software related to Java virtual machines,
related class libraries, and other software commonly associated with
Java platform implementations; and be it further
RESOLVED, that the office of "Vice President, Harmony" be and hereby
is created, the person holding such office to serve at the direction
of the Board of Directors as the chair of the Harmony PMC, and to have
primary responsibility for management of the projects within the scope
of responsibility of the Harmony PMC; and be it further
RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Harmony PMC:
* Nathan Beyer ([EMAIL PROTECTED])
* Tim Ellison([EMAIL PROTECTED])
* Mark Hindess ([EMAIL PROTECTED])
* George Harley ([EMAIL PROTECTED])
* Mikhail Loenko ([EMAIL PROTECTED])
* Geir Magnusson Jr. ([EMAIL PROTECTED])
* Stepan Mishura ([EMAIL PROTECTED])
* Weldon Washburn([EMAIL PROTECTED])
* Paulex Yang([EMAIL PROTECTED])
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Geir Magnusson Jr be
appointed to the office of Vice President, Harmony, to serve in
accordance with and subject to the direction of the Board of Directors
and the Bylaws of the Foundation until death, resignation, retirement,
removal or disqualification, or until a successor is appointed; and be
it further
RESOLVED, that the initial Harmony PMC be and hereby is tasked with
the creation of a set of bylaws intended to encourage open development
and increased participation in the Harmony Project; and be it further
RESOLVED, that the initial Harmony PMC be and hereby is tasked with
the migration and rationalization of the Apache Incubator Harmony
podling; and be it further
RESOLVED, that all responsibility pertaining to the Apache Incubator
Harmony podling encumbered upon the Apache Incubator PMC are hereafter
discharged.
- 0 -
Comments please?
geir
--
Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][awt] headless support
Martin Cordova wrote: (e.g. for linux we need to exclude all xlib calls, right?). << How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Could it be that native code is simply linked to these libraries so native awt code libraries just don't load if you don't have X libraries in the system? -- Gregory Shimansky, Intel Middleware Products Division
Re: svn commit: r467552 - in /incubator/harmony/enhanced/drlvm/trunk/vm: tests/smoke/StackTest.java vmcore/src/util/ia32/base/compile_IA32.cpp vmcore/src/util/linux/signals_ia32.cpp vmcore/src/util/wi
on_catch_callback);
}
-
linux_regs_to_ucontext(uc, ®s);
}
@@ -272,6 +271,7 @@
inline size_t find_guard_stack_size() {
return 64*1024;
+
}
inline size_t find_guard_page_size() {
@@ -318,34 +318,39 @@
void set_guard_stack() {
int err;
-/*
- * have the stack parameters been initialized?
- *
- * TODO - fix this - this probably should be elsewhere
- */
-
-if(!p_TLS_vmthread->stack_addr) {
-init_stack_info();
-}
-
char* stack_addr = (char*) get_stack_addr();
size_t stack_size = get_stack_size();
size_t guard_stack_size = get_guard_stack_size();
size_t guard_page_size = get_guard_page_size();
-err = mprotect(stack_addr - stack_size + guard_page_size +
guard_stack_size,
-guard_page_size, PROT_NONE);
+// map the guard page and protect it
+void UNUSED *res = mmap(stack_addr - stack_size + guard_page_size +
+guard_stack_size, guard_page_size, PROT_READ | PROT_WRITE,
+MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+
+assert(res!=MAP_FAILED);
+
+err = mprotect(stack_addr - stack_size + guard_page_size +
+guard_stack_size, guard_page_size, PROT_NONE );
+
+assert(!err);
+
+//map the alternate stack on which we want to handle the signal
+void UNUSED *res2 = mmap(stack_addr - stack_size + guard_page_size,
+guard_stack_size, PROT_READ | PROT_WRITE,
+MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+
+assert(res2!=MAP_FAILED);
+
-/* $$$ GMJassert(!err); */
-
stack_t sigalt;
sigalt.ss_sp = stack_addr - stack_size + guard_page_size;
sigalt.ss_flags = SS_ONSTACK;
sigalt.ss_size = guard_stack_size;
err = sigaltstack (&sigalt, NULL);
-
assert(!err);
+
}
size_t get_available_stack_size() {
@@ -376,8 +381,10 @@
size_t guard_stack_size = get_guard_stack_size();
size_t guard_page_size = get_guard_page_size();
-err = mprotect(stack_addr - stack_size + guard_page_size +
guard_stack_size,
-guard_page_size, PROT_READ | PROT_WRITE);
+
+err = mprotect(stack_addr - stack_size + guard_page_size +
+guard_stack_size, guard_page_size, PROT_READ | PROT_WRITE);
+
stack_t sigalt;
sigalt.ss_sp = stack_addr - stack_size + guard_page_size;
@@ -385,6 +392,7 @@
sigalt.ss_size = guard_stack_size;
err = sigaltstack (&sigalt, NULL);
+
}
bool check_stack_overflow(siginfo_t *info, ucontext_t *uc) {
@@ -395,6 +403,7 @@
char* guard_page_begin = stack_addr - stack_size + guard_page_size +
guard_stack_size;
char* guard_page_end = guard_page_begin + guard_page_size;
+
char* fault_addr = (char*)(info->si_addr);
//char* esp_value = (char*)(uc->uc_mcontext.gregs[REG_ESP]);
@@ -432,7 +441,7 @@
}
void null_java_reference_handler(int signum, siginfo_t* UNREF info, void*
context)
-{
+{
ucontext_t *uc = (ucontext_t *)context;
Global_Env *env = VM_Global_State::loader_env;
@@ -443,7 +452,7 @@
stack_overflow_handler(signum, info, context);
return;
}
-
+
if (env->shutting_down != 0) {
fprintf(stderr, "null_java_reference_handler(): called in
shutdown stage\n");
} else if (!interpreter_enabled()) {
@@ -452,7 +461,6 @@
return;
}
}
-
fprintf(stderr, "SIGSEGV in VM code.\n");
Registers regs;
linux_ucontext_to_regs(®s, uc);
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?view=diff&rev=467552&r1=467551&r2=467552
==
---
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp
(original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp
Tue Oct 24 20:55:30 2006
@@ -176,17 +176,6 @@
}
void set_guard_stack() {
-
-/*
- * have the stack parameters been initialized?
- *
- * TODO - fix this - this probably should be elsewhere
- */
-
- if(!p_TLS_vmthread->stack_addr) {
-init_stack_info();
-}
-
void* stack_addr = get_stack_addr();
size_t stack_size = get_stack_size();
size_t page_size = get_guard_page_size();
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][smoke_test] running kernel classes tests on DRLVM compiled with Intel Compiler (linux/ia32)
Nataly Naumova wrote: On 10/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: BTW to test how things work with Intel compiler I've installed it on Gentoo (version 9.1.042, it is marked as unstable, but the most recent "stable" is very old - 7.1.006... which version do you use?) and failed to compile drlvm with it. Something is wrong with thread manager linking build.native.link: [cc] 0 total files to be compiled. [cc] Starting link [cc] ld: tm_self_tls: TLS definition in ../_obj/thread_native_basic.o section .tbss mismatches non-TLS reference in ../_obj/thread_native_condvar.o [cc] ../_obj/thread_native_condvar.o: could not read symbols: Bad value BUILD FAILED Does anyone know what's wrong and how to fix it? I tried to understand how tm_self_tls is defined and couldn't, because its definition and usage in different files is quite complicated. Maybe I need newer binutils (current version is 2.16.1-r3 - latest stable), the "Bad value" seems to hint on this. My binutils version is 2.15.91.0.2. Yours are newer.. Could you also tell me which version of icc you are using? -- Gregory Shimansky, Intel Middleware Products Division
