Re: [general] Harmony Todo list
that's not half as fun as people setting their mailer to change the reply-to: to the list and then sending personal mail... ;) geir Orlov, Alexander M wrote: Folks, I'm awfully sorry, that should have been personal letter. If you don't understand Russian just ignore it. If you understand it please ignore it too. My favorite mistake to Reply to the mailing list and not change the recipient. :) Thanks, Alex. -Original Message- From: Orlov, Alexander M [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 11:32 AM To: harmony-dev@incubator.apache.org Subject: RE: [general] Harmony Todo list What's the procedure for this? Certificate of origin, etc? Is the code scan required before that? I can create a JIRA with the sources attached but the problem is they're changed often. Антоха, я могу ошибаться, но вроде бы COO и код скан - это такие внутренние Интеловские прибамбасы. :) Саня. -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 11:28 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] Harmony Todo list Stefano, - move 'harmonytest.org' source code in the harmony svn repository so that others can work on it What's the procedure for this? Certificate of origin, etc? Is the code scan required before that? I can create a JIRA with the sources attached but the problem is they're changed often. (actually, I think we should host the harmony testing in our own zone and avoid depending on Alexey's own resources, but there is no hurry for that). Yes, that'd be great. Fitting it to hosting that is more suitable for home pages is a pain in the brain. -- Regards, Anton Luht, Intel Java XML Engineering
Re: [general] Harmony Todo list
Anton Luht wrote: Stefano, - move 'harmonytest.org' source code in the harmony svn repository so that others can work on it What's the procedure for this? Certificate of origin, etc? Is the code scan required before that? I can create a JIRA with the sources attached but the problem is they're changed often. Who wrote it? (actually, I think we should host the harmony testing in our own zone and avoid depending on Alexey's own resources, but there is no hurry for that). Yes, that'd be great. Fitting it to hosting that is more suitable for home pages is a pain in the brain.
Re: [drlvm][x86_64] status update
Don't pat my back. Stefano and Gregory hammered through some of the latest cruft - I just followed the email thread and formalized and committed the changes. geir Tim Ellison wrote: Good progress. pat on back/ Regards, Tim Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir
Re: [drlvm][x86_64] status update
Pavel Ozhdikhin wrote: Just FYI: I was able to build Classlib + DRLVM on SLES 9 64-bit. The only difficulty was to build libjpeg, libpng and liblcms manually, otherwise everything went fine. why manually? $ uname -a Linux xx 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux $ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java version 1.5.0 pre-alpha : not complete or compatible svn = r476058, (Nov 17 2006), Linux/em64t/gcc 3.3.3, debug build http://incubator.apache.org/harmony $ How about running the tests? I can run java -version too. And even run simple programs. It's the tests that show failures (not all, some) geir Thanks, Pavel On 11/17/06, Tim Ellison [EMAIL PROTECTED] wrote: Good progress. pat on back/ Regards, Tim Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [drlvm][x86_64] status update
Pavel Afremov wrote: Hi. On my EM64T machines wit SuSE 9 and SuSE 10 I can't reproduce crash. StackTest and FinalizerStackTest return FAILED status. Frankly speaking any tests crashed VM on my EM64T machine without unset JAVA_HOME. With unset all tests work, but .as I said StackTest and FinalizerStackTest return FAILED status. Yah, I get failed status too. Because the VM segfaults. Try running StackTest via ./java StackTest and what do you see? Oh, reading more... I try to fix of guard page creating on the EM64T thread stack as for ia32. StackTest and FinalizerStackTest start work and return PASSED. Can you explain that fix? But gc.Force and others became fail. The source, as I understand, is in following: after mmap of the stack, java method Object.wait() can't works. SuSE 10 hangs up, SuSE 9 makes exit on it I'm just marveling over the fact you got gdb to work. Can anyone else w/ Ubunutu 32-bit or 64-bit debug drlvm in a reasonable way? Gdb shows sigsegv in #0 0x002a961d489d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x002a957a7501 in apr_thread_cond_wait (cond=Variable cond is not available.) at thread_cond.c:68 #2 0x002a957a3e85 in condvar_wait_impl (cond=0x2aaa309778, mutex=0x2aaa309728, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_condvar.c:69 #3 0x002a957a4463 in monitor_wait_impl (mon_ptr=0x2aaa3096c8, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_fat_monitor.c:208 #4 0x002a957a652b in thin_monitor_wait_impl (lockword_ptr=0x2a98c24e54, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:430 #5 0x002a957a65b1 in hythread_thin_monitor_wait_interruptable (lockword_ptr=0x2a98c24e54, ms=0, nano=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:482 #6 0x002a96b97f15 in jthread_monitor_timed_wait (monitor=0x7fbfffcbc8, millis=0, nanos=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_java_monitors.c:337 #7 0x002a96a29a08 in Java_java_lang_VMThreadManager_wait (env=0x594c58, clazz=0x7fbfffcbc0, monitor=0x7fbfffcbc8, millis=0, nanos=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/vmcore/src/kernel_classes/native/java_lang_VMThreadManager.cpp:202 In HARMONY-2224 https://issues.apache.org/jira/browse/HARMONY-2224 I excluded failed tests from acceptance test set: StackTest exception.FinalizerStackTest on EM64T gc.LOS on Windows. I'll go check this out immediately geir BR. Pavel Afremov On 11/17/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Rana Dasgupta wrote: Not surprising :-) The last big stack relatad checkin in 2018. Its comment notes say that Gregory actually saw the failure of StackTest and the new FinalizeStackTest... So... lets fix them... :) geir On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: First test that fails is the most cherished and beloved StackTest, with a segmentation fault :) I'll try to find some more useful info... geir Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir
Re: [classlib][linux/x86_32] classlib doesn't buid if X11 is not present
Here's the instructions I had ready for the website, but got clobbered with one of the many doco patches. I'll put on website today in terms of requirement, and then point to a wiki for details for this platform. 1) Install subversion, gcc, g++ and make: [EMAIL PROTECTED]:~$ sudo apt-get install subversion [EMAIL PROTECTED]:~$ sudo apt-get install gcc [EMAIL PROTECTED]:~$ sudo apt-get install g++ [EMAIL PROTECTED]:~$ sudo apt-get install make 3) Install java : (1.5.0_9 from sun) 4) Install ant (1.6.x) 4) Get junit and drop the junit-X.jar into ant/lib 4) Install AWT/Swing deps apt-get install liblcms1-dev apt-get install libpng12-dev apt-get install libjpeg62-dev apt-get install libx11-dev apt-get install libxft-dev apt-get install binutils-dev 5) Get harmony tree : [EMAIL PROTECTED]:~/dev/apache/harmony/enhanced/trunk$ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk 6) populate source subtrees : $ cd trunk $ ant populate_source 7) build classlib $ cd working_classlib $ ant fetch-depends $ ant Stefano Mazzocchi wrote: [copy] Copying 1 file to /home/stefano/src/classlib/deploy/jdk/jre/bin [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/home/stefano/src/classlib/deploy/include -I/home/stefano/src/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I/usr/X11R6/include -I/usr/include/freetype2 -Iinclude-c -o LinuxNativeFont.o LinuxNativeFont.c [exec] LinuxNativeFont.c:22:25: error: X11/Xft/Xft.h: No such file or directory [exec] LinuxNativeFont.c:23:31: error: freetype/tttables.h: No such file or directory [exec] LinuxNativeFont.c:24:31: error: freetype/t1tables.h: No such file or directory [exec] LinuxNativeFont.c:39:39: error: freetype/internal/tttypes.h: No such file or directory [exec] LinuxNativeFont.c:43:31: error: freetype/ftsnames.h: No such file or directory [exec] In file included from LinuxNativeFont.c:56: [exec] LinuxNativeFont.h:61: error: expected specifier-qualifier-list before ‘FT_Int’ [exec] LinuxNativeFont.c: In function I'm trying to compile classlib on a x86_32 debian server I have access to but it doesn't have X installed, can i compile without it? if not, what is the minimum set of packages I need?
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
My thinking is that we should support the convention, but we're also trying to create another convention with VMI. Would the vmi.dll be usable by other implementors? geir Tim Ellison wrote: Geir Magnusson Jr. wrote: We are doing this to conform to some convention, right? If the covention for jvm.dll is a standard invocation API, why would we also bundle in the harmony-specific VMI API? No, take a look at the exports from a jvm.dll, it is the standard invocation API + vm-specific APIs. I suggest we do the same (though in our case it is the two additional Harmony-specific VMI functions). Why not keep that separate and try to push that forward as a convention as well? Why try create another convention when there is one in use in the wild? Regards, Tim
Re: svn commit: r475458 - /incubator/harmony/enhanced/admin/README.txt
thank you. I'm happy. geir Tim Ellison wrote: Geir Magnusson Jr. wrote: from the admin section? No, the notice is in here [1], in the section Export Notice. It is predominantly boilerplate text. The readme in the admin section is for 'us' harmony types to show why that bis file is there, and record the e-mail sent to Uncle Sam. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/README.txt?revision=474645view=markup Regards, Tim Tim Ellison wrote: The bis_HARMONY.rdf file isn't actually shipped, it is just used to generate the artefacts for the ASF webpages and US Gov e-mail. The notice to our users is put in the readme that goes into our releases. Regards, Tim Geir Magnusson Jr. wrote: maybe we should put this in our regular NOTICE file? [EMAIL PROTECTED] wrote: Author: tellison Date: Wed Nov 15 14:11:04 2006 New Revision: 475458 URL: http://svn.apache.org/viewvc?view=revrev=475458 Log: Add readme with explanation of bis export file. Added: incubator/harmony/enhanced/admin/README.txt (with props) Added: incubator/harmony/enhanced/admin/README.txt URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/admin/README.txt?view=autorev=475458 == --- incubator/harmony/enhanced/admin/README.txt (added) +++ incubator/harmony/enhanced/admin/README.txt Wed Nov 15 14:11:04 2006 @@ -0,0 +1,13 @@ +Apache Harmony Export Notification +== + +The file bis_HARMONY.rdf in this directory should not be +moved/renamed since it is referenced directly from the ASF +export registry. + +Details of the export requirements are given here +http://www.apache.org/dev/crypto.html + +The e-mail sent to the US Government is archived here + http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/raw/[EMAIL PROTECTED] + Propchange: incubator/harmony/enhanced/admin/README.txt -- svn:eol-style = native
Re: [general][testing] cruise control on the WinXP and SUSE linux
the [EMAIL PROTECTED] did go through, I think. That has been added as an allow. Can you try again? Vladimir Ivanov wrote: On 11/17/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: Seems, I was over-optimistic :( To test notifications I add my email together with '[EMAIL PROTECTED]' and broke ws. But I received only 1 notification and seems it was for my address only. Any ideas? Now I try to run it with notification from my gmail address. Seems, it also works for me only: - *From:* [EMAIL PROTECTED] *Sent:* Friday, November 17, 2006 3:45 PM *To:* [EMAIL PROTECTED]; Ivanov, Vladimir A *Subject:* [continuum] Win XP 1CPU msvc: drlvm drlvm-test Build Failed *Importance:* High BUILD FAILED Thanks, Vlaidmir
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Tim Ellison wrote:
Before you go off writing more code, just take a moment to look at
HARMONY-263 and tell us what you think of it.
It ties us to JUnit. Doesn't moving the exclude list upwards give us
more freedom?
geir
Thanks
Tim
Alexei Zakharov wrote:
Hi Vladimir,
It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.
For example, we can put exclude lists into something like:
exclude.xml:
---
exclude-list
!-- exclude only particular tests --
class name=org.apache.harmony.luni.test.java.io.MyTest
test name=testConstructor11/
test name=testMyMethodObjectObjectString_HY1234/
/class
!-- exclude all tests --
class name=org.apache.harmony.luni.test.java.io.NiceTest2
includeAll=true/
...
/exclude-list
exclude.linux.drlvm.xml:
---
exclude-list
class name=org.apache.harmony.rmi.test.java.rmi.ВadBoyTest
test name=testLinuxHang_my/
/class
/exclude-list
And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.
IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?
Thanks,
2006/11/15, Vladimir Ivanov [EMAIL PROTECTED]:
Seems, we says about different things :)
First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.
Also, in my vision these exclude-lists are like a buffer before we
mark test
by correct tags.
When the test fails on some platform we update the corresponding
x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.
Thanks, Vladimir
On 11/15/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)
Thanks,
2006/11/15, Vladimir Ivanov [EMAIL PROTECTED]:
As part of solution for this issue the
*HARMONY-2197*http://issues.apache.org/jira/browse/HARMONY-2197 was
created.
I suggest using the separate exclude list for each platform. I
hope in
this
case the test enabling for the different platforms will be easy.
Please,
look at it.
Any comments are welcome :)
Thanks, Vladimir
On 11/15/06, Alexei Fedotov [EMAIL PROTECTED] wrote:
Pavel, you are correct. Rana, sorry for confusion. Both issues
block
passing class library unit tests.
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution
http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one
contains
three diffrent issues, and I cannot say where exactly the
problem is.
On 11/15/06, Pavel Afremov [EMAIL PROTECTED] wrote:
As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?
Pavel Afremov.
On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
OK thanks Pavel, I'll try the patch today.
Rana
On 11/8/06, Pavel Afremov [EMAIL PROTECTED] wrote:
Hi Rana.
I extend guard region as work around. It's only one way,
which
fix
SOE
on
my SuSE Linux, without potential regression of your fix.
On my
Linux
machine
violation access signals happen one page before protected
page
on
the
stack.
It's it.
I ran all tests, and everything was OK. But strange
misprint was
fount
in
the new test.
So I attach new fixed patch.
Pavel Afremov.
On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Though I tried several times, I could not repro 2070 or
Alexey's
specific
problems. The test attached to 2018 repros, and that I
think
is
enough.
Pavel,
1. The patch looks good, but I could not apply and try it
since
my
Linux
box is down.
2. Did you run all tests ( smoke, cuint, kernel, and
classlib )?
Since
this fully turns on lazy exceptions, we need to ensure that
all
tests
pass,
or at least have identical behaviour before and after the
pacth.
3. Adding a finalizer based stack test to smoke is a good
idea.
4. On Linux
Re: [drlvm][x86_64] status update
isn't there a package manager that will let you fetch liblcms? Pavel Ozhdikhin wrote: On 11/17/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Pavel Ozhdikhin wrote: Just FYI: I was able to build Classlib + DRLVM on SLES 9 64-bit. The only difficulty was to build libjpeg, libpng and liblcms manually, otherwise everything went fine. why manually? My system does not have liblcms so I had to build in from source. Then classlib build complained that it can not link with other libraries or something like that (sorry, I've re-written the log already) and I had to rebuild them as well. If you want to know particular error message I can reproduce the problem. $ uname -a Linux xx 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux $ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java version 1.5.0 pre-alpha : not complete or compatible svn = r476058, (Nov 17 2006), Linux/em64t/gcc 3.3.3, debug build http://incubator.apache.org/harmony http://incubator.apache.org/harmony $ How about running the tests? I can run java -version too. And even run simple programs. It's the tests that show failures (not all, some) I was able to run SPECjbb2005. Have not run the tests yet. Thanks, Pavel geir Thanks, Pavel On 11/17/06, Tim Ellison [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Good progress. pat on back/ Regards, Tim Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir -- Tim Ellison ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [general] Harmony Todo list
All alone? Then as long as your employer doesn't consider it a work for hire - IOW, if Intel doesn't think that they paid you to do this - then you can contribute it yourself. Please check with your manager. If that is ok, then you can submit as a JIRA and as Tim noted, we'll put in 'standard'... geir Anton Luht wrote: Who wrote it? The code? Me. (actually, I think we should host the harmony testing in our own zone and avoid depending on Alexey's own resources, but there is no hurry for that). Yes, that'd be great. Fitting it to hosting that is more suitable for home pages is a pain in the brain.
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
I spoke too soon - do you mean reusing the code for managing the exclude
lists?
geir
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
Before you go off writing more code, just take a moment to look at
HARMONY-263 and tell us what you think of it.
It ties us to JUnit. Doesn't moving the exclude list upwards give us
more freedom?
geir
Thanks
Tim
Alexei Zakharov wrote:
Hi Vladimir,
It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.
For example, we can put exclude lists into something like:
exclude.xml:
---
exclude-list
!-- exclude only particular tests --
class name=org.apache.harmony.luni.test.java.io.MyTest
test name=testConstructor11/
test name=testMyMethodObjectObjectString_HY1234/
/class
!-- exclude all tests --
class name=org.apache.harmony.luni.test.java.io.NiceTest2
includeAll=true/
...
/exclude-list
exclude.linux.drlvm.xml:
---
exclude-list
class name=org.apache.harmony.rmi.test.java.rmi.ВadBoyTest
test name=testLinuxHang_my/
/class
/exclude-list
And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.
IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?
Thanks,
2006/11/15, Vladimir Ivanov [EMAIL PROTECTED]:
Seems, we says about different things :)
First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.
Also, in my vision these exclude-lists are like a buffer before we
mark test
by correct tags.
When the test fails on some platform we update the corresponding
x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.
Thanks, Vladimir
On 11/15/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)
Thanks,
2006/11/15, Vladimir Ivanov [EMAIL PROTECTED]:
As part of solution for this issue the
*HARMONY-2197*http://issues.apache.org/jira/browse/HARMONY-2197 was
created.
I suggest using the separate exclude list for each platform. I
hope in
this
case the test enabling for the different platforms will be easy.
Please,
look at it.
Any comments are welcome :)
Thanks, Vladimir
On 11/15/06, Alexei Fedotov [EMAIL PROTECTED] wrote:
Pavel, you are correct. Rana, sorry for confusion. Both issues
block
passing class library unit tests.
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution
http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one
contains
three diffrent issues, and I cannot say where exactly the
problem is.
On 11/15/06, Pavel Afremov [EMAIL PROTECTED] wrote:
As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
Alexei, is it correct? If not, could you clarify the point about
exn_raise_by_name_internal in your initial letter, please?
Pavel Afremov.
On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
OK thanks Pavel, I'll try the patch today.
Rana
On 11/8/06, Pavel Afremov [EMAIL PROTECTED] wrote:
Hi Rana.
I extend guard region as work around. It's only one way,
which
fix
SOE
on
my SuSE Linux, without potential regression of your fix.
On my
Linux
machine
violation access signals happen one page before protected
page
on
the
stack.
It's it.
I ran all tests, and everything was OK. But strange
misprint was
fount
in
the new test.
So I attach new fixed patch.
Pavel Afremov.
On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Though I tried several times, I could not repro 2070 or
Alexey's
specific
problems. The test attached to 2018 repros, and that I
think
is
enough.
Pavel,
1. The patch looks good, but I could not apply and try it
since
my
Linux
box is down.
2. Did you run all tests ( smoke, cuint, kernel, and
classlib )?
Since
this fully turns on lazy exceptions, we need to ensure that
all
tests
pass,
or at least have identical
Re: [ot] getting silly
You know someone is going to spin this... see, they even do all their development discussion in Russian... geir Tim Ellison wrote: Вы можете пойти здесь http://babelfish.altavista.com/. Будет сериями потехи! Как наблюдать рыбу те велосипед. :-) Time to get back to the code me thinks. Tim Alexei Zakharov wrote: +1 Intelovskiye is just the exact spelling of the russian pronunciation. It is interesting how it translates this back to Russian. :-D 17.11.06, Mikhail Loenko[EMAIL PROTECTED] написал(а): LOL 17.11.06, Tim Ellison[EMAIL PROTECTED] написал(а): Orlov, Alexander M wrote: Folks, I'm awfully sorry, that should have been personal letter. If you don't understand Russian just ignore it. If you understand it please ignore it too. My favorite mistake to Reply to the mailing list and not change the recipient. :) Don't worry, we all do it. And for fun of course I had to paste it into BabelFish (I learnt Russian at school for two years, but that was a _long_ time ago). I don't wish to embarrass you, I just thought it was funny that you said (apparently): Antokha, I can make mistakes, but like COO and the code is scan - these are such internal Intelovskiye pribambasy. I particularly like Intelovskiye :-)
Re: [drlvm][kernel_classes] ThreadLocal vulnerability
I grok this. I have no problem.
geir
Tim Ellison wrote:
Thomas Hawtin wrote:
I had a quick browse through the Harmony SVN and spotted what appears to
be a vulnerability in the java.lang.ThreadLocal implementation. I have
briefly discussed this with Tim Ellison and Geir Magnusson Jr., off list
before posting here.
Yep, and I'll say again publicly, thank you for looking through the code
so carefully, and taking the time to report your findings.
Harmony uses a per Thread HashMap (WeakHashMap in classlibadapter) to
map ThreadLocals onto values. HashMaps (should) check for equality with
Object.equals and Object.hashCode instead of == and
System.identityHashCode.
As you correctly point out, Harmony's implementation of
java.lang.ThreadLocal [2] delegates storing the thread local values to
the instance of java.lang.Thread to which they apply.
In Harmony the implementation of Thread is a kernel type, provided
separately by each VM.
The code in classlibadapter [1] was an experiment to map between the
Harmony kernel types and GNU Classpath's VM interface types. That work
is not in current usage, and is not being actively maintained.
The current active kernel code in Harmony is the DRLVM. Looking at
DRLVM's version of Thread here [3], it uses a (non-weak) HashMap like this:
void setThreadLocal(ThreadLocalObject local, Object value) {
if (localValues == null) {
localValues = new HashMapThreadLocalObject, Object();
}
localValues.put(local, value);
}
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlibadapter/trunk/modules/kernel/src/main/java/java/lang/Thread.java?view=markup
[2]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/ThreadLocal.java?revision=451251view=markup
[3]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/javasrc/java/lang/Thread.java?revision=471005view=markup
Malicious subclasses of ThreadLocal can override hashCode to run through
all possible hash codes, extracting all the ThreadLocals present in the
current thread through an overridden equals. Some of these ThreadLocals
may contain sensitive values. Even if Harmony generates identity hash
codes entirely at random, the process should be completable in the order
of a few minutes of CPU time.
Tim Ellison suggests replacing the HashMap with an IdentityHashMap. I
agree that this would fix the security vulnerability.
Anyone else care to comment on this as a proposed fix?
Some modern code,
such as I believe Spring, creates many ThreadLocal instances, so you may
wish to look further at quality of implementation issues.
Ack -- thanks. What do you call many? 100's? 1,000s? more?
FWIW, I believe early versions of Sun's 1.3 J2SE suffered a similar
problem.
Regards,
Tim
Re: [drlvm] Java stack limits
Tim Ellison wrote: Geir Magnusson Jr. wrote: I think that it's totally unreasonable to have no upper bound on stack size. A Java virtual machine should never be able to hose a machine by sucking in all memory... yeah, like those rotten C programs. You are damned if you do and damned if you don't, since you'll upset people who hit any arbitrary limit that you set on the stack size too. As we have seen, current impls do limit. Clearly the suck all memory until the box turns over and wiggles it's feet in the air setting isn't needed by anyone. Is there some reasonable heuristic based on heap defaults or settings? geir Regards, Tim
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
ok... Tim Ellison wrote: Geir Magnusson Jr. wrote: My thinking is that we should support the convention, but we're also trying to create another convention with VMI. Would the vmi.dll be usable by other implementors? Not really, since implementers have to hold on to our VMI function struct from the JavaVM / JNIEnv, and we can't write that portably (across implementations). Regards, Tim
Re: [general][testing] cruise control on the WinXP and SUSE linux
Hm. Ok - I just sent my own test. I do have it allowed. I'll try to get this to work myself as spoofing from [EMAIL PROTECTED] and see how it works out... geir Vladimir Ivanov wrote: On 11/17/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: the [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] did go through, I think. That has been added as an allow. Can you try again? Seems, nothing was changed :( I received it 13 minutes ago but don't see anything on harmony-commits. ** *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Sent:* Friday, November 17, 2006 8:40 PM *To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]; Ivanov, Vladimir A *Subject:* [continuum] Win XP 1CPU msvc: classlib classlib Build Failed *Importance:* High = Vladimir Ivanov wrote: On 11/17/06, Vladimir Ivanov [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Seems, I was over-optimistic :( To test notifications I add my email together with '[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]' and broke ws. But I received only 1 notification and seems it was for my address only. Any ideas? Now I try to run it with notification from my gmail address. Seems, it also works for me only: - *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Sent:* Friday, November 17, 2006 3:45 PM *To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]; Ivanov, Vladimir A *Subject:* [continuum] Win XP 1CPU msvc: drlvm drlvm-test Build Failed *Importance:* High BUILD FAILED Thanks, Vlaidmir
Re: [performance] a few early benchmarks
Stefano Mazzocchi wrote: Alexey Varlamov wrote: Stefano, It is a bit unfair to compare *debug* build of Harmony with other release versions :) I'm simulating what a journalist with a developer could do. Our snapshots are built in release mode. If there is a way to make it compile in 'release mode' (if such a thing exists), I'll be very glad to redo the benchmarks. export BUILD_CFG=release sh build.sh clean sh build.sh
Re: [classlib][linux/x86_32] classlib doesn't buid if X11 is not present
Stefano Mazzocchi wrote: Geir Magnusson Jr. wrote: Here's the instructions I had ready for the website, but got clobbered with one of the many doco patches. I'll put on website today in terms of requirement, and then point to a wiki for details for this platform. 1) Install subversion, gcc, g++ and make: [EMAIL PROTECTED]:~$ sudo apt-get install subversion [EMAIL PROTECTED]:~$ sudo apt-get install gcc [EMAIL PROTECTED]:~$ sudo apt-get install g++ [EMAIL PROTECTED]:~$ sudo apt-get install make 3) Install java : (1.5.0_9 from sun) 4) Install ant (1.6.x) 4) Get junit and drop the junit-X.jar into ant/lib 4) Install AWT/Swing deps apt-get install liblcms1-dev apt-get install libpng12-dev apt-get install libjpeg62-dev apt-get install libx11-dev apt-get install libxft-dev apt-get install binutils-dev You might need to add sudo here too I wasn't going to presume. :)
Re: [classlib][linux/x86_32] classlib doesn't buid if X11 is not present
remember, we have a page on the website that details this. The stuff you see below is just for config... these were my notes, so the stuff at the end should be removed... Stefano Mazzocchi wrote: Stefano Mazzocchi wrote: Geir Magnusson Jr. wrote: Here's the instructions I had ready for the website, but got clobbered with one of the many doco patches. I'll put on website today in terms of requirement, and then point to a wiki for details for this platform. 1) Install subversion, gcc, g++ and make: [EMAIL PROTECTED]:~$ sudo apt-get install subversion [EMAIL PROTECTED]:~$ sudo apt-get install gcc [EMAIL PROTECTED]:~$ sudo apt-get install g++ [EMAIL PROTECTED]:~$ sudo apt-get install make 3) Install java : (1.5.0_9 from sun) 4) Install ant (1.6.x) 4) Get junit and drop the junit-X.jar into ant/lib 4) Install AWT/Swing deps apt-get install liblcms1-dev apt-get install libpng12-dev apt-get install libjpeg62-dev apt-get install libx11-dev apt-get install libxft-dev apt-get install binutils-dev You might need to add sudo here too 5) Get harmony tree : [EMAIL PROTECTED]:~/dev/apache/harmony/enhanced/trunk$ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk 6) populate source subtrees : $ cd trunk $ ant populate_source 7) build classlib $ cd working_classlib $ ant fetch-depends $ ant This is awesome! let's get this up on the web site/wiki ASAP ah, don't forget to add instructions for the VM as well
[build-test] Tracking platforms and architecure for CI
I put a wiki page up : http://wiki.apache.org/harmony/Automated_Testing (reachable from the front page) to capture how we track and govern the community CI effort that build-test is intended to be. So I didn't set out any rules other than someone who's interested has to approach the community (we do gatekeep as we need to manually let mail through to -commits) and note that we reserve the right to refuse anyone. Right now, there's a table that lists the CI going on at IBM. Once Vladimir's machine is sending mail through, we'll add that, and we'll add the build-test running on my x86_64/Ubuntu6 when that's working. geir
[doc] HOW-TOs for configuration dev machines
I put the notes I made on doing ubuntu 6 on a wiki page http://wiki.apache.org/harmony/DevelopmentPlatformConfiguration Please provide details for other platforms if you have them. geir
Re: [drlvm][x86_64] status update
I'm happy to disable tests. I was disappointed in 2224 - I assumed that it was an external exclude list :) But I guess that works. How do we exclude for more than 1 platform? geir Rana Dasgupta wrote: Hi, Sadly, I still run or debug any of this yet. But my suggestion and request would be that we commit Pavel's patch 2224 which for now disables the overfow tests on EM64T. That would give us some time to understand and debug the problem. We are good on 32 bit. The bottom line is that the main thread stack growth and mapping behaviour and guard paging seems to vary across Linux implementations, specially between older and more current implementations. Some behaviour could also be specific to SUSE. We will figure out what is the best and broadest solution. Thanks, Rana On 11/17/06, Pavel Afremov [EMAIL PROTECTED] wrote: Yes, of cause... partially :) 1) mprotect can't work on main application thread without mmap. Rana found out this fact. I think I can explain it, but it is guess only. I can't find description of it in google... Also on different versions of Linux behavior is different. 2) Rana implemented call of mmap for protected page to call mprotect for it. But it's not enough on some Linux. On my machines sigsegv happened one page before guard page in this case. I suppose that OS check next page status before allocate requested page for the stack. And if next page is already mmapped - OS decides that stack can't grow and sigsegv is happened. Theoretically stack of the thread can grow infinitely especially on EM64T platform. 3) I checked mapped areas for the debugged VM and found, that for others threads, not main thread, whole stack mapped at once. So I tried to map whole stack for main thread in the beginning of the work, at once. And it works. Thanks Pavel Afremov. But gc.Force and others became fail. The source, as I understand, is in following: after mmap of the stack, java method Object.wait() can't works. SuSE 10 hangs up, SuSE 9 makes exit on it I'm just marveling over the fact you got gdb to work. Can anyone else w/ Ubunutu 32-bit or 64-bit debug drlvm in a reasonable way? Gdb shows sigsegv in #0 0x002a961d489d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x002a957a7501 in apr_thread_cond_wait (cond=Variable cond is not available.) at thread_cond.c:68 #2 0x002a957a3e85 in condvar_wait_impl (cond=0x2aaa309778, mutex=0x2aaa309728, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_condvar.c:69 #3 0x002a957a4463 in monitor_wait_impl (mon_ptr=0x2aaa3096c8, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_fat_monitor.c:208 #4 0x002a957a652b in thin_monitor_wait_impl (lockword_ptr=0x2a98c24e54, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:430 #5 0x002a957a65b1 in hythread_thin_monitor_wait_interruptable (lockword_ptr=0x2a98c24e54, ms=0, nano=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:482 #6 0x002a96b97f15 in jthread_monitor_timed_wait (monitor=0x7fbfffcbc8, millis=0, nanos=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_java_monitors.c:337 #7 0x002a96a29a08 in Java_java_lang_VMThreadManager_wait (env=0x594c58, clazz=0x7fbfffcbc0, monitor=0x7fbfffcbc8, millis=0, nanos=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/vmcore/src/kernel_classes/native/java_lang_VMThreadManager.cpp:202 In HARMONY-2224 https://issues.apache.org/jira/browse/HARMONY-2224 I excluded failed tests from acceptance test set: StackTest exception.FinalizerStackTest on EM64T gc.LOS on Windows. I'll go check this out immediately geir BR. Pavel Afremov On 11/17/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Rana Dasgupta wrote: Not surprising :-) The last big stack relatad checkin in 2018. Its comment notes say that Gregory actually saw the failure of StackTest and the new FinalizeStackTest... So... lets fix them... :) geir On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: First test that fails is the most cherished and beloved StackTest, with a segmentation fault :) I'll try to find some more useful info... geir Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs
Re: [drlvm][x86_64] status update
I was hoping you wouldn't say that. Time to modify the DRLVM build for testing. sob geir Pavel Afremov wrote: On 11/17/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm happy to disable tests. I was disappointed in 2224 - I assumed that it was an external exclude list :) But I guess that works. How do we exclude for more than 1 platform? It's impossible, as I understand. Pavel Afremov geir Rana Dasgupta wrote: Hi, Sadly, I still run or debug any of this yet. But my suggestion and request would be that we commit Pavel's patch 2224 which for now disables the overfow tests on EM64T. That would give us some time to understand and debug the problem. We are good on 32 bit. The bottom line is that the main thread stack growth and mapping behaviour and guard paging seems to vary across Linux implementations, specially between older and more current implementations. Some behaviour could also be specific to SUSE. We will figure out what is the best and broadest solution. Thanks, Rana On 11/17/06, Pavel Afremov [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes, of cause... partially :) 1) mprotect can't work on main application thread without mmap. Rana found out this fact. I think I can explain it, but it is guess only. I can't find description of it in google... Also on different versions of Linux behavior is different. 2) Rana implemented call of mmap for protected page to call mprotect for it. But it's not enough on some Linux. On my machines sigsegv happened one page before guard page in this case. I suppose that OS check next page status before allocate requested page for the stack. And if next page is already mmapped - OS decides that stack can't grow and sigsegv is happened. Theoretically stack of the thread can grow infinitely especially on EM64T platform. 3) I checked mapped areas for the debugged VM and found, that for others threads, not main thread, whole stack mapped at once. So I tried to map whole stack for main thread in the beginning of the work, at once. And it works. Thanks Pavel Afremov. But gc.Force and others became fail. The source, as I understand, is in following: after mmap of the stack, java method Object.wait() can't works. SuSE 10 hangs up, SuSE 9 makes exit on it I'm just marveling over the fact you got gdb to work. Can anyone else w/ Ubunutu 32-bit or 64-bit debug drlvm in a reasonable way? Gdb shows sigsegv in #0 0x002a961d489d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x002a957a7501 in apr_thread_cond_wait (cond=Variable cond is not available.) at thread_cond.c:68 #2 0x002a957a3e85 in condvar_wait_impl (cond=0x2aaa309778, mutex=0x2aaa309728, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_condvar.c:69 #3 0x002a957a4463 in monitor_wait_impl (mon_ptr=0x2aaa3096c8, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_fat_monitor.c:208 #4 0x002a957a652b in thin_monitor_wait_impl (lockword_ptr=0x2a98c24e54, ms=0, nano=0, interruptable=1) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:430 #5 0x002a957a65b1 in hythread_thin_monitor_wait_interruptable (lockword_ptr=0x2a98c24e54, ms=0, nano=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:482 #6 0x002a96b97f15 in jthread_monitor_timed_wait (monitor=0x7fbfffcbc8, millis=0, nanos=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_java_monitors.c:337 #7 0x002a96a29a08 in Java_java_lang_VMThreadManager_wait (env=0x594c58, clazz=0x7fbfffcbc0, monitor=0x7fbfffcbc8, millis=0, nanos=0) at /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/vmcore
[drlvm][x86_64] test status
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?
Re: [drlvm][unit] 100% of class library tests pass
Mikhail Loenko wrote: why not? Because the full-stack testing is appropriate for CI systems that are running full-time to catch bugs. That's what our build-test infrastructure is all about. Asking DRLVM developers (and conversely, classlib developers) to run 1+ hours of tests for even the smallest commits is a waste of time. We simply need to balance efficiency (targeted testing when you make a fix) with the dedication to have a rapid response when the CI systems find a problem. geir 2006/11/16, Geir Magnusson Jr. [EMAIL PROTECTED]: Pavel Ozhdikhin wrote: On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Be sure to not miss anyone :) This was a great community effort, with everyone pitching in. DRLVM is now a full peer to J9 in Harmony testing. :) We still need to use J9 (and another VM that happens to work with our classlibrary), as a sanity check, but we should from now on use DRLVM in our CI testing framework. On the other hand, to make sure DRLVM has no regressions regarding to Classlibrary Unit Tests it makes sense to add these tests to the test target of DRLVM build. What do people think? Adding classlib unit tests to DRLVM test target? No thanks :) geir Thanks, Pavel geir Alexei Fedotov wrote: Oops, I've missed: * Andrew Zhang for reviewing class library patches and helpful discussions On 11/16/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Folks, According to http://harmonytest.org, today 100% of class library unit tests pass on DRLVM. Thank you all! It takes 44 days for the great team we are. Thanks for your thoughtful, diligent work and deep inspiration. Kudos to you for the following (and not limited to this): * Alexey Varlamov and Elena for driving the whole process * Anton and Vladimir Ivanov for automating test runs * Geir and Gregory for checking and committing related DRLVM patches * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and committing related class library patches * Alexey Petrenko for becoming ICU expert and writing good JIRA issue resolution guidelines * Alexei Zakharov for resolving class library test issues * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay Sidelnikov and Alexander Astapchuk for making execution engines work * Tatiana and Maxim for filing JIRA issues about test failures * Nikolay Kuznetsov for completing thread interruption handling and reverting consequences of park/unpark integration * Pavel Afremov for fixing exception handling * Boris Kuznetsov for intelligent fixing of security tests * Rana and Salikh for evaluating and discussing problems, reviewing and trying DRLVM patches * Pavel Pervov and Evgueni for help with DRLVM patches * Artem for discovering and fixing weird Windows* behavior * My wife for bringing hot tea to the computer during sleepless nights There are still open issues with reliability, multiprocessor and other special configurations, so the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM remains active. But this shouldn't prevent us from including class library testing into Harmony zero regression policy. What do you think? -- Thank you, Alexei
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'm not sure I meant that as a literal fork, but rather a spawned process in which we can set the ulimit indep of the invoking parent. 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. I think that it's totally unreasonable to have no upper bound on stack size. A Java virtual machine should never be able to hose a machine by sucking in all memory... geir
Re: svn commit: r475458 - /incubator/harmony/enhanced/admin/README.txt
from the admin section? Tim Ellison wrote: The bis_HARMONY.rdf file isn't actually shipped, it is just used to generate the artefacts for the ASF webpages and US Gov e-mail. The notice to our users is put in the readme that goes into our releases. Regards, Tim Geir Magnusson Jr. wrote: maybe we should put this in our regular NOTICE file? [EMAIL PROTECTED] wrote: Author: tellison Date: Wed Nov 15 14:11:04 2006 New Revision: 475458 URL: http://svn.apache.org/viewvc?view=revrev=475458 Log: Add readme with explanation of bis export file. Added: incubator/harmony/enhanced/admin/README.txt (with props) Added: incubator/harmony/enhanced/admin/README.txt URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/admin/README.txt?view=autorev=475458 == --- incubator/harmony/enhanced/admin/README.txt (added) +++ incubator/harmony/enhanced/admin/README.txt Wed Nov 15 14:11:04 2006 @@ -0,0 +1,13 @@ +Apache Harmony Export Notification +== + +The file bis_HARMONY.rdf in this directory should not be +moved/renamed since it is referenced directly from the ASF +export registry. + +Details of the export requirements are given here +http://www.apache.org/dev/crypto.html + +The e-mail sent to the US Government is archived here + http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/raw/[EMAIL PROTECTED] + Propchange: incubator/harmony/enhanced/admin/README.txt -- svn:eol-style = native
Re: [general][testing] cruise control on the WinXP and SUSE linux
please locally break something (IOW, no need to check in...), get CC to send the message, so then we can all rest comfortably that failures do lead to email. geir Vladimir Ivanov wrote: Thanks, today this test passed on both machines :( I hope, the CC will send notification if this test fail again. Now, notifications should be sending to harmony-commits list from the [EMAIL PROTECTED] address. Thanks, Vladimir On 11/16/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 11/15/06, Vladimir Ivanov wrote: Sorry, I can't use the [EMAIL PROTECTED] mail address. Sorry again, to test it I use the [EMAIL PROTECTED] as for IBM notifications without ask for permission :( Could somebody register some fake mail address in the harmony-commits to use it for my CC notifications or I should use other alias or may be other options exist? Thanks, Vladimir By the way, now my CC reports for both systems: Unit Test Error Details: (1)Test: test_Sign Class: org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest junit.framework.AssertionFailedError at org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest.test_Sign ( DigitalSignatureTest.java:135) at java.lang.reflect.VMReflection.invokeMethod(Native Method) Hm, ... strange. The test passes for me on Linux and Windows. This is regression test for JSSE provider and it goes with a fix for the provider. So it can fail if CC doesn't perform classlib rebuild. And I believe it does. Is the failure stable for you? Can you reproduce it? Thanks, Stepan. On 11/15/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 15.11.06, Gregory Shimansky[EMAIL PROTECTED] написал(а): 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.3on SuSE9 doesn't report. Good point, I support this. -- Alexey -- Gregory -- Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general][testing] cruise control on the WinXP and SUSE linux
Stepan Mishura wrote: Vladimir, Sorry, I didn't follow discussions about build-and-test infra. I've done check out of build-and-test workspace and I'm trying to set up it. I have some questions: - README.txt file says about downloading IBM VME and I guess you run CC on DRL VM. Does the file is up to date? No - that was written before DRLVM could do this :) - 'ant setup' fetches CruiseControl and sets it up. But why I should fetch classlib dependencies manually? IMHO, 'ant setup' should do it too. Again, early days... the patches should fix... Thanks, Stepan. On 11/16/06, Vladimir Ivanov wrote: Thanks, today this test passed on both machines :( I hope, the CC will send notification if this test fail again. Now, notifications should be sending to harmony-commits list from the [EMAIL PROTECTED] address. Thanks, Vladimir On 11/16/06, Stepan Mishura wrote: On 11/15/06, Vladimir Ivanov wrote: Sorry, I can't use the [EMAIL PROTECTED] mail address. Sorry again, to test it I use the [EMAIL PROTECTED] as for IBM notifications without ask for permission :( Could somebody register some fake mail address in the harmony-commits to use it for my CC notifications or I should use other alias or may be other options exist? Thanks, Vladimir By the way, now my CC reports for both systems: Unit Test Error Details: (1)Test: test_Sign Class: org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest junit.framework.AssertionFailedError at org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest.test_Sign ( DigitalSignatureTest.java:135) at java.lang.reflect.VMReflection.invokeMethod(Native Method) Hm, ... strange. The test passes for me on Linux and Windows. This is regression test for JSSE provider and it goes with a fix for the provider. So it can fail if CC doesn't perform classlib rebuild. And I believe it does. Is the failure stable for you? Can you reproduce it? Thanks, Stepan. On 11/15/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 15.11.06, Gregory Shimansky[EMAIL PROTECTED] написал(а): 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.3on SuSE9 doesn't report. Good point, I support this. Alexey
Re: [jira][attachments] Is it possible to mark attachments as obsolete?
Alexey Petrenko wrote: 2006/11/15, Geir Magnusson Jr. [EMAIL PROTECTED]: I wonder if there is any harm in deleting them? 1. Not all the JIRA users can delete attachements. 2. Sometimes history is good. I agree #2. We can always fix #1. Maybe then someone just writes down best practices somewhere. SY, Alexey Alexey Petrenko wrote: I'm using All issue view. It shows all the comments and attachment in time ordered way... This helps. But marking attachments as obsolete will be better :) SY, Alexey 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.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
I dont' care, but as you said, have it search for both for now... Tim Ellison wrote: Oliver Deakin (JIRA) wrote: [classlib][luni] Add creation of stub jvm.dll to luni module Key: HARMONY-2201 URL: http://issues.apache.org/jira/browse/HARMONY-2201 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Oliver Deakin Priority: Minor It is standard practise when writing a VM launcher to link against invocation API providing libraries called jvm.dll/libjvm.so. The RI and J9 VMs both follow the convention of placing a jvm.lib file (on Windows) into jdk/lib, and the actual jvm.dll/libjvm.so in the appropriate place under jre/bin. Harmony differs from this convention in two ways: 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This means that any Windows user writing a custom launcher will not be able to make calls to our invocation API. It makes sense in this case to create a stubbed set of invocation API natives to build a jvm.lib in the appropriate place. We currently do something similar to create a stubbed vmi.lib for linking against. 2) The libraries providing the invocation API are currently called harmonyvm.dll/libharmonyvm.so. I would suggest that these are renamed to jvm.dll/libjvm.so to follow the conventional naming scheme. This seems like an eminently reasonable suggestion. Anyone object? If not I'll hack the jvm.lib and make the launcher look for both names to allow for a transition. Regards, Tim
Re: [drlvm][em64t] build fails
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. Of course. The JVM should never take down the whole machine.
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
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.
Re: [jira] Patch available setting
Egor Pasko wrote: On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote: Egor Pasko wrote: On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote: I thought we had it configured that when a JIRA is modified, the reporter is notified directly... I'm not sure that really helps though. I wonder if we should just open things up a bit and let any user modify a JIRA and see what happens. reporters are notified, that's right But what if reporter=patch publisher? Then someone still needs to review. Sometimes, reporters are not familiar with the components fixed, someone needs to pick up a review in this case too. That's why I watch things I'm interested in. I just look at all Harmony JIRA notifications. There are a lot, but most can be safely skipped by subject. Right - do a watch on the JIRAs you are interested in - they come to you directly, not to the project JIRA stream. Is there any other way to be notified with new issues than to subscribe for the whole JIRA stream? I would love to use it. I want to be sure to get the whole stream, and then just filter for things I want to look for. Unless this is something that lots of people need - having a separate new JIRA mail stream, I think that you might want to try that :) geir P.S: watch is a good feature, I have been using it. geir geir Sian January wrote: Hi, I have just discovered that it's not possible for a contributor to set Patch available on a JIRA unless they reported it. (I'm not sure about committers as I'm not one...) I imagine this is to stop people coming in and editing other details on the JIRA, so I can see that it makes sense. My question is, what is the best thing to do if I attach a patch to a JIRA and I can't set Patch available? I can think of three alternatives at the moment: 1. Assume that the reporter will notice and set it themselves (or commit the fix if they're also a comitter) 2. E-mail the reporter privately 3. Post to the mailing list Or a fourth alternative would be a combination of the above where the person who contributed the patch waits a few days before doing either 2 or 3. Any thoughts on what would be best? Thanks, Sian
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Tim Ellison wrote: Mikhail Loenko wrote: Is this lib VM-specific? No, er, yes, er, ... let me try to explain. In the jre/bin/vm sub directories we have harmonyvm.dll's (which are VM-specific), but we use the name and function export convention to code against any compliant impl. The RI others call their equivalent jvm.dll so the proposal is that we do the same for Harmony's convention because... ...we currently don't provide a harmonyvm.lib to link against in our jdk/lib directory, and apps that embed the VM would expect to have that. Yeah - I just had to work around that w/ my embedding eperiment. The idea would be to create a stub (like we do for the vmi.lib) and leave the concrete code in the vm-specific subdirs. Again, calling this jvm.lib means we look and feel just like the RI which helps users. If users really want to hard link against a particular VM-impl then we can provide non-stub jvm.lib's in the vm-specific subdirectories (again like the vmi.lib). Now I've written all that, I it's clear that we should roll the VMI functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll would export both sets of functions, i.e. JNI_CreateJavaVM JNI_GetCreatedJavaVMs JNI_GetDefaultJavaVMInitArgs VMI_GetVMIFromJNIEnv VMI_GetVMIFromJavaVM What do you thing? Why? What's wrong with both? Seems clearer to separate, and prevents charges of vendor lock in :) Are we going to have one more VM-specific lib in the common dir? Do you mean threadlib? It's destined to become common code. Regards, Tim 2006/11/16, Tim Ellison [EMAIL PROTECTED]: Oliver Deakin (JIRA) wrote: [classlib][luni] Add creation of stub jvm.dll to luni module Key: HARMONY-2201 URL: http://issues.apache.org/jira/browse/HARMONY-2201 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Oliver Deakin Priority: Minor It is standard practise when writing a VM launcher to link against invocation API providing libraries called jvm.dll/libjvm.so. The RI and J9 VMs both follow the convention of placing a jvm.lib file (on Windows) into jdk/lib, and the actual jvm.dll/libjvm.so in the appropriate place under jre/bin. Harmony differs from this convention in two ways: 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This means that any Windows user writing a custom launcher will not be able to make calls to our invocation API. It makes sense in this case to create a stubbed set of invocation API natives to build a jvm.lib in the appropriate place. We currently do something similar to create a stubbed vmi.lib for linking against. 2) The libraries providing the invocation API are currently called harmonyvm.dll/libharmonyvm.so. I would suggest that these are renamed to jvm.dll/libjvm.so to follow the conventional naming scheme. This seems like an eminently reasonable suggestion. Anyone object? If not I'll hack the jvm.lib and make the launcher look for both names to allow for a transition. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [drlvm][unit] 100% of class library tests pass
Mikhail Loenko wrote: Well let's see how often we will break CI systems. If we break it twice a day then pre-commit testing needs to be strengthened. Right. Exactly. Iterate and adapt. BTW if compile in release mode then all classlib tests run 35 minutes on DRLVM. Once we fix DRLVM to run with the fork mode once it will be even faster... Thanks, Mikhail 2006/11/16, Geir Magnusson Jr. [EMAIL PROTECTED]: Mikhail Loenko wrote: why not? Because the full-stack testing is appropriate for CI systems that are running full-time to catch bugs. That's what our build-test infrastructure is all about. Asking DRLVM developers (and conversely, classlib developers) to run 1+ hours of tests for even the smallest commits is a waste of time. We simply need to balance efficiency (targeted testing when you make a fix) with the dedication to have a rapid response when the CI systems find a problem. geir 2006/11/16, Geir Magnusson Jr. [EMAIL PROTECTED]: Pavel Ozhdikhin wrote: On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Be sure to not miss anyone :) This was a great community effort, with everyone pitching in. DRLVM is now a full peer to J9 in Harmony testing. :) We still need to use J9 (and another VM that happens to work with our classlibrary), as a sanity check, but we should from now on use DRLVM in our CI testing framework. On the other hand, to make sure DRLVM has no regressions regarding to Classlibrary Unit Tests it makes sense to add these tests to the test target of DRLVM build. What do people think? Adding classlib unit tests to DRLVM test target? No thanks :) geir Thanks, Pavel geir Alexei Fedotov wrote: Oops, I've missed: * Andrew Zhang for reviewing class library patches and helpful discussions On 11/16/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Folks, According to http://harmonytest.org, today 100% of class library unit tests pass on DRLVM. Thank you all! It takes 44 days for the great team we are. Thanks for your thoughtful, diligent work and deep inspiration. Kudos to you for the following (and not limited to this): * Alexey Varlamov and Elena for driving the whole process * Anton and Vladimir Ivanov for automating test runs * Geir and Gregory for checking and committing related DRLVM patches * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and committing related class library patches * Alexey Petrenko for becoming ICU expert and writing good JIRA issue resolution guidelines * Alexei Zakharov for resolving class library test issues * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay Sidelnikov and Alexander Astapchuk for making execution engines work * Tatiana and Maxim for filing JIRA issues about test failures * Nikolay Kuznetsov for completing thread interruption handling and reverting consequences of park/unpark integration * Pavel Afremov for fixing exception handling * Boris Kuznetsov for intelligent fixing of security tests * Rana and Salikh for evaluating and discussing problems, reviewing and trying DRLVM patches * Pavel Pervov and Evgueni for help with DRLVM patches * Artem for discovering and fixing weird Windows* behavior * My wife for bringing hot tea to the computer during sleepless nights There are still open issues with reliability, multiprocessor and other special configurations, so the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM remains active. But this shouldn't prevent us from including class library testing into Harmony zero regression policy. What do you think? -- Thank you, Alexei
Re: [general] Harmony Todo list
Stefano Mazzocchi wrote: here is what I think Harmony needs: - a logo [no feather BS, something cool and trendy that we could print on mugs and t-shirts... and no duke crap either] I was so hoping no one would suggest this... - professionally-looking web pages They're coming along - move 'harmonytest.org' source code in the harmony svn repository so that others can work on it (actually, I think we should host the harmony testing in our own zone and avoid depending on Alexey's own resources, but there is no hurry for that). Yep - continue the work on the 'buildtest' infrastructure and make it dump results automatically in harmonytest, but identifying the IP address and the OS and the various environment features (like gcc version and so on) Yep - I think it does that already. - identify benchmarks that we want to run against harmony and add those to buildtest so that they dump 'performance' information yep - plot results of such performance over time and send email in case a major regression occurs. yep Thoughts? Anything else? Lots :) geir
Re: [build-test] Moving from /enhanced to /standard
Just curious... what else could it be? Weldon Washburn wrote: On 11/16/06, Tim Ellison [EMAIL PROTECTED] wrote: Just to be clear that you are referring to moving [1] from enhanced to standard? If I understood that right, then +1. +1, same assumptions as Tim. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/buildtest/ Regards, Tim Geir Magnusson Jr. wrote: Does anyone care? This way, we can be freer about who and what goes in there. Since we don't ship the testing frameworks with anything, this is completely consistent with our IP policies and goals. geir -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Tim Ellison wrote: Geir Magnusson Jr. wrote: Tim Ellison wrote: Now I've written all that, I it's clear that we should roll the VMI functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll would export both sets of functions, i.e. JNI_CreateJavaVM JNI_GetCreatedJavaVMs JNI_GetDefaultJavaVMInitArgs VMI_GetVMIFromJNIEnv VMI_GetVMIFromJavaVM What do you thing? Why? What's wrong with both? Seems clearer to separate, and prevents charges of vendor lock in :) You'll have to explain that comment to me. Today, to use the VM a program has to load a particular implementation of harmonyvm.dll, and our classlib code links against vmi.lib and uses a particular vmi.dll. I'm proposing that to use the VM any program can link against jvm.lib but has to load a particular implementation of jvm.dll; and our classlib code also links against jvm.lib and uses the same jvm.dll. How is the second scenario harmony-specific and not the first? We are doing this to conform to some convention, right? If the covention for jvm.dll is a standard invocation API, why would we also bundle in the harmony-specific VMI API? Why not keep that separate and try to push that forward as a convention as well? geir
Re: [general] Harmony Todo list
Chris Gray wrote: On Thursday 16 November 2006 19:39, Stefano Mazzocchi wrote: [...] (WTF does BSD licensing for a logo mean, anyway?), It means that you don't have to distribute the source code of the logo :-), but it has to be accompanied by 200+ words of copyright notice and you can't use Sun's name to endorse your competition-winning graphic ... meaning that all 'java look-alikes' will have duke [...] Mika will never have duke, so long as I live. The coffe cup maybe, but not the pointy-headed red-nosed cretin. There are limits. :-) it's a tooth. An engorged tooth. With arms. geir
Re: svn commit: r475971 - /incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Gregory Shimansky wrote:
On Friday 17 November 2006 02:13 [EMAIL PROTECTED] wrote:
Author: geirm
+!--
+ * FIXME : the following awful little hack is because we noticed
that for whatever + * reason, we can't link with libjpg.a on at
least to kinds of 65-bit linux + --
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...
geir
+target name=-check-unix-common
+property name=png.msg
+ 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 /
+mkdir dir=depends/libs/build/png /
+check-one-link src=${png.home}/include/pngconf.h
+dest=depends/libs/build/png/pngconf.h
+message=${png.msg} /
+check-one-link src=${png.home}/include/png.h
+dest=depends/libs/build/png/png.h
+message=${png.msg} /
+
+property name=jpeg.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 /
+mkdir dir=depends/libs/build/jpeg /
+check-one-link src=${jpeg.home}/include/jconfig.h
+dest=depends/libs/build/jpeg/jconfig.lnx
+message=${jpeg.msg} /
+check-one-link src=${jpeg.home}/include/jpeglib.h
+dest=depends/libs/build/jpeg/jpeglib.h
+message=${jpeg.msg} /
+check-one-link src=${jpeg.home}/include/jmorecfg.h
+dest=depends/libs/build/jpeg/jmorecfg.h
+message=${jpeg.msg} /
+check-one-link src=${jpeg.home}/include/jerror.h
+dest=depends/libs/build/jpeg/jerror.h
+message=${jpeg.msg} /
+/target
+
+target name=-check-unix-x86 if=is.x86
depends=-check-unix-common +check-one-link
src=${png.home}/lib/libpng.a
+
dest=depends/libs/build/png/libpng.${hy.platform} +
message=${png.msg} /
+
+check-one-link src=${jpeg.home}/lib/libjpeg.a
+
dest=depends/libs/build/jpeg/libjpeg.${hy.platform} +
message=${jpeg.msg} /
+/target
+
+target name=-check-unix-x86_64 if=is.x86_64
depends=-check-unix-common +check-one-link
src=${png.home}/lib/libpng.so
+
dest=depends/libs/build/png/libpng.${hy.platform} +
message=${png.msg} /
+
+check-one-link src=${jpeg.home}/lib/libjpeg.so
+
dest=depends/libs/build/jpeg/libjpeg.${hy.platform} +
message=${jpeg.msg} /
+/target
+
+target name=-check-unix if=is.unix depends=-check-unix-x86,
-check-unix-x86_64
property name=lcms.msg
value=liblcms development package not installed
@@ -102,7 +161,7 @@
message=${lcms.msg} /
-property name=png.msg
+ !-- property name=png.msg
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
@@ -119,7 +178,7 @@
message=${png.msg} /
-property name=jpeg.msg
+ property name=jpeg.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
@@ -140,6 +199,7 @@
check-one-link src=${jpeg.home}/include/jerror.h
dest=depends/libs/build/jpeg/jerror.h
message=${jpeg.msg} /
+--
/target
Re: [drlvm][unit] 100% of class library tests pass
Alexei Fedotov wrote: Pavel, The life started showing that you were correct. Today there were no report on http://harmonytest.org. Even if I would like to be a living notification, I couldn't. Vladimir, The thing which concerns me most is not an absence of results - I believe this is just a technical problem. For me the main problem is that without you there is no way to understand what happens. I don't understand that. The goal here is to establish the build-test framework as the thing that everyone uses- we aren't dependent only upon Vladimir. I'll have a version running on 64-bit ubuntu whenever it works, and probalby 32-bit as well reporting in... Can we made a process of reporting more open? For example, can we tune CC to send a notification on upload status? If there is a successful notification, then the file is uploaded successfully, and we need to ask Anton why it is not visible. Otherwise we'll know the problem is in CC. Um. I'd prefer if we didn't spam the lists with every good result - we only want to know when there's breakage or fixage. geir Thanks! On 11/16/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Sorry to say but it actually does not work until there is no notifications to the mailing list and no immediate reaction to the regressions. thanks, Pavel On 11/16/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Pavel, All, Let me add one pro for the second approach: it works already. Vladimir's scripts daily upload test results to http://harmonytest.org. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 12:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit] 100% of class library tests pass Pavel Ozhdikhin wrote: We have to evolving systems - classlib and DRLVM. To check commits to classlib we need a stable DRLVM which can pass 100% of HUT. Otherwise it's impossible to use DRLVM for pre-commit testing - you never know whether your test fail because of your patch or due to latest changes in DRLVM. I remember the time when DRLVM and Jitrino actively evolved - for some time JIT had to use an older version of DRLVM which could pass all commit criteria because newer versions suffered from regressions. And finally we came to comon strict commit criteria which prevented regressions in both VM and JIT. To avoid regressions using DRLVM in classlib testing I see 3 possible solutions: 1. Use one fixed DRLVM version which can pass 100% HUT test. Update this version from time to time. Pros: + Less time to run DRLVM pre-commit tests + Classlib does not suffer from regressions in DRLVM Cons: - DRLVM will suffer from regressions - Classlib can not use the latest DRLVM - Need additional efforts to regain stability on DRLVM when we want to update the version for classlib testing 2. Add HUT to CruiseControl testing on DRLVM and rollback commits causing regressions Pros: + Less time to run DRLVM pre-commit tests + Classlib can use the latest DRLVM Cons: - Classlib can suffer from DRLVM regressions (time lag before rollback) - It is not always clear which commit caused a regression - Rollbacks are costly 3. Add HUT to the commit criteria for DRLVM Pros: + Classlib always can use the latest DRLVM + DRLVM has no regressions regarding to HUT Cons: - More time to run DRLVM pre-commit tests (I was told that HUT take 25 minutes running in single JVM mode) I think that preventing a problem is better than solving it afterwards. So, I personally would choose the 3rd approach, don't mind against the second and dislike the first one. Probably some combination of these is possible. While I appreciate the desire to keep things stable, I think it is unreasonable to ask developers to run the entire test suite each time. As we have seen in the classlib code, running targeted tests before commit and leaving the build machines to run continuous tests ensures that we are productive and are notified of breakages in time to easily back out a patch and re-evaluate. With the amount of machine time we have running harmony tests on different cpu's/os's/compilers/etc we are getting better coverage than any individual could be expected to provide. Which is a long way of saying I think option (2) above is best -- and relies on the bid machines letting us know if things break, and the commitment from all of us to go straight in and fix it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[drlvm][x86_64] status update
We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir
Re: [drlvm][x86_64] status update
First test that fails is the most cherished and beloved StackTest, with a segmentation fault :) I'll try to find some more useful info... geir Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir
Re: [general] Announcing Melody
bugs? We don't have bugs. They are contribution opportunities :) geir Jin Mingjian wrote: Good! Do you plan to add some bugs-related charts?
Re: [drlvm][x86_64] status update
Rana Dasgupta wrote: Not surprising :-) The last big stack relatad checkin in 2018. Its comment notes say that Gregory actually saw the failure of StackTest and the new FinalizeStackTest... So... lets fix them... :) geir On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: First test that fails is the most cherished and beloved StackTest, with a segmentation fault :) I'll try to find some more useful info... geir Geir Magnusson Jr. wrote: We now have DRLVM+Classlib cleanly building out of SVN and able to run basic programs on Ubuntu 6 on an em64T box. $ 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/Linux Now starting to look into the test suite. Tests are passing, but I've just started... Well done, everyone! geir
Re: [drlvm][unit] New regression? org.apache.harmony.auth.tests.javax.security.auth.kerberos.serialization.KrbDelegationPermissionCollectionTest
what VM? Alexei Fedotov wrote: Folks, Has anyone seen the following problem in the whole test run? I cannot reproduce the problem for standalone test. (SuSE 9) testcase classname=org.apache.harmony.auth.tests.javax.security.auth.kerberos.serialization.KrbDelegationPermissionCollectionTest name=testGolden time=0.047 error type=java.io.IOExceptionjava.io.IOException at java.io.IOException.lt;initgt;(IOException.java:35) at org.apache.harmony.luni.platform.OSFileSystem.close(OSFileSystem.java:203) at java.io.FileInputStream.close(FileInputStream.java:174) at org.apache.harmony.nio.internal.FileChannelImpl.implCloseChannel(FileChannelImpl.java:102) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:98) at java.io.FileInputStream.close(FileInputStream.java:167) at java.io.FilterInputStream.close(FilterInputStream.java) at java.io.BufferedInputStream.close(BufferedInputStream.java:121) at java.io.FilterInputStream.close(FilterInputStream.java) at java.io.ObjectInputStream.close(ObjectInputStream.java) at org.apache.harmony.testframework.serialization.SerializationTest.getObjectFromStream(SerializationTest.java:201) at org.apache.harmony.testframework.serialization.SerializationTest.getObject(SerializationTest.java:520) at org.apache.harmony.testframework.serialization.SerializationTest.verifyGolden(SerializationTest.java:428) at org.apache.harmony.testframework.serialization.SerializationTest.verifyGolden(SerializationTest.java:402) at org.apache.harmony.testframework.serialization.SerializationTest.testGolden(SerializationTest.java:146) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at org.apache.harmony.testframework.serialization.SerializationTest.runBare(SerializationTest.java:111) /error /testcase
Re: [drlvm][x86_64] status update
it is amazing, since we make them by the truck load :) I've been trying to figure it out - not making much progress as it hoses gdb. Seems like I'm back to Ye Olde Printf School of Debugging. Mañanna... time for sleep geir Rana Dasgupta wrote: Sadly I am sans a 64 bit Linux box at least temporarily. Sounds hard to believe, I know... On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Rana Dasgupta wrote: Not surprising :-) The last big stack relatad checkin in 2018. Its comment notes say that Gregory actually saw the failure of StackTest and the new FinalizeStackTest... So... lets fix them... :) geir
Re: TSU NOTIFICATION - Encryption
thx Tim Ellison wrote: SUBMISSION TYPE: TSU SUBMITTED BY: Tim Ellison SUBMITTED FOR:The Apache Software Foundation POINT OF CONTACT: Secretary, The Apache Software Foundation FAX: +1-410-803-2258 MANUFACTURER(S): The Apache Software Foundation, The Legion Of The Bouncy Castle PRODUCT NAME/MODEL #: Apache Harmony ECCN: 5D002 NOTIFICATION: http://www.apache.org/licenses/exports/
Re: [gump] Gump running on Harmony!!
w00t! (the server has been heating my office... I can tell when Gump is running as the fans spin up...) geir 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?
Re: [general][testing] cruise control on the WinXP and SUSE linux
Yep! Will enable the notications... 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 Thanks, Vladimir
Re: [general][testing] cruise control on the WinXP and SUSE linux
I've allowed the mail through.. 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 Thanks, Vladimir
Re: [gump] Gump running on Harmony!!
Stefano Mazzocchi wrote: Tim Ellison wrote: Stefano Mazzocchi wrote: The first problem is the lack of javac that bootstrap-ant requires. Can you clarify what 'bootstrap-ant' requires? Is it running an Ant javac task, or compiling Ant source with javac.exe? I was assuming the latter. bootstrap-ant is a script that builds ant without ant, so it requires having the javac executable available. I could cheat and symlink jikes to it, but I don't want to do that: Gump is an indicator of what people use in real life and this is the first sign that harmony needs a javac command in order to proceed in real-life usefulness and I want to keep that signal clear. We know :) So, if you are curious to see what's the next roadblock, I suggest that one of you starts coding a javac wrapper for ecj (or anything else that would do the job, I don't care) ;-) We have one somewhere...
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Rana Dasgupta wrote:
I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.
We can't depend on this - they have to mechanically resolve as passed or
failed.
Can you give me an example of a test?
On 11/15/06, Alexei Fedotov [EMAIL PROTECTED] 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?
Thanks!
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
--
Thank you,
Alexei
Re: [jira][attachments] Is it possible to mark attachments as obsolete?
I wonder if there is any harm in deleting them? geir Alexey Petrenko wrote: I'm using All issue view. It shows all the comments and attachment in time ordered way... This helps. But marking attachments as obsolete will be better :) SY, Alexey 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.
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
I like this approach. +1 (it's exactly how I would have done it. :) Vladimir Ivanov wrote: As part of solution for this issue the *HARMONY-2197*http://issues.apache.org/jira/browse/HARMONY-2197 was created. I suggest using the separate exclude list for each platform. I hope in this case the test enabling for the different platforms will be easy. Please, look at it. Any comments are welcome :) Thanks, Vladimir On 11/15/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Pavel, you are correct. Rana, sorry for confusion. Both issues block passing class library unit tests. http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread] Unhandled exception in java.exe while java.util.jar module tests execution http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit] org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest I've used a debugger and caught an assert in exn_raise_by_name_internal for the second one. The first one contains three diffrent issues, and I cannot say where exactly the problem is. On 11/15/06, Pavel Afremov [EMAIL PROTECTED] wrote: As I understand Alexey means HARMONY-2073, but not HARMONY-2070. Alexei, is it correct? If not, could you clarify the point about exn_raise_by_name_internal in your initial letter, please? Pavel Afremov. On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote: OK thanks Pavel, I'll try the patch today. Rana On 11/8/06, Pavel Afremov [EMAIL PROTECTED] wrote: Hi Rana. I extend guard region as work around. It's only one way, which fix SOE on my SuSE Linux, without potential regression of your fix. On my Linux machine violation access signals happen one page before protected page on the stack. It's it. I ran all tests, and everything was OK. But strange misprint was fount in the new test. So I attach new fixed patch. Pavel Afremov. On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Though I tried several times, I could not repro 2070 or Alexey's specific problems. The test attached to 2018 repros, and that I think is enough. Pavel, 1. The patch looks good, but I could not apply and try it since my Linux box is down. 2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since this fully turns on lazy exceptions, we need to ensure that all tests pass, or at least have identical behaviour before and after the pacth. 3. Adding a finalizer based stack test to smoke is a good idea. 4. On Linux you extend the guard region up ( or down whatever ) by a page. Did you find a good reason for it, or is this just being careful? Rana On 11/7/06, Pavel Afremov [EMAIL PROTECTED] wrote: Rana, Everything is correct in you description, but it looks like that * HARMONY-2018* https://issues.apache.org/jira/browse/HARMONY-2018 should fix described bug. I think Alexei will have a chance to check it. Thank you. Pavel Afremov. -- Thank you, Alexei
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
We should also take a hard look at how to do this in DRLVM as well... Vladimir Ivanov wrote: Seems, we says about different things :) First of all, we have no TestNG (or other harness) yet but we need now different exclude lists for different platforms. Also, in my vision these exclude-lists are like a buffer before we mark test by correct tags. When the test fails on some platform we update the corresponding x-list and investigate this failure. As the result of investigation we mark the test or fix it. Thanks, Vladimir On 11/15/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Things become more and more complicated. Can anyone say why we rejected to use TestSuites for this purpose from the very beginning? Well, I can't say I am against using xml lists here. But the next step will be to keep list of individual failing test methods in the xml file. Then to create separate xml lists for api and impl tests and so on. If we can't run original TestNG on Harmony then we invent it by ourselves. :-) Thanks, 2006/11/15, Vladimir Ivanov [EMAIL PROTECTED]: As part of solution for this issue the *HARMONY-2197*http://issues.apache.org/jira/browse/HARMONY-2197 was created. I suggest using the separate exclude list for each platform. I hope in this case the test enabling for the different platforms will be easy. Please, look at it. Any comments are welcome :) Thanks, Vladimir On 11/15/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Pavel, you are correct. Rana, sorry for confusion. Both issues block passing class library unit tests. http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread] Unhandled exception in java.exe while java.util.jar module tests execution http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit] org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest I've used a debugger and caught an assert in exn_raise_by_name_internal for the second one. The first one contains three diffrent issues, and I cannot say where exactly the problem is. On 11/15/06, Pavel Afremov [EMAIL PROTECTED] wrote: As I understand Alexey means HARMONY-2073, but not HARMONY-2070. Alexei, is it correct? If not, could you clarify the point about exn_raise_by_name_internal in your initial letter, please? Pavel Afremov. On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote: OK thanks Pavel, I'll try the patch today. Rana On 11/8/06, Pavel Afremov [EMAIL PROTECTED] wrote: Hi Rana. I extend guard region as work around. It's only one way, which fix SOE on my SuSE Linux, without potential regression of your fix. On my Linux machine violation access signals happen one page before protected page on the stack. It's it. I ran all tests, and everything was OK. But strange misprint was fount in the new test. So I attach new fixed patch. Pavel Afremov. On 11/8/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Though I tried several times, I could not repro 2070 or Alexey's specific problems. The test attached to 2018 repros, and that I think is enough. Pavel, 1. The patch looks good, but I could not apply and try it since my Linux box is down. 2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since this fully turns on lazy exceptions, we need to ensure that all tests pass, or at least have identical behaviour before and after the pacth. 3. Adding a finalizer based stack test to smoke is a good idea. 4. On Linux you extend the guard region up ( or down whatever ) by a page. Did you find a good reason for it, or is this just being careful? Rana On 11/7/06, Pavel Afremov [EMAIL PROTECTED] wrote: Rana, Everything is correct in you description, but it looks like that * HARMONY-2018* https://issues.apache.org/jira/browse/HARMONY-2018 should fix described bug. I think Alexei will have a chance to check it. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [gump] Gump running on Harmony!!
That's odd. The launcher should figure this out. I'll take a look in a sec... Stefano Mazzocchi wrote: Gregory Shimansky wrote: 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? First of all, remember that Gump is written in python and uses 'java' just like any other command, but the environment around that command might not exactly be the same as the one from the shell. I'm not sure of the details of that. Anyway, when Gump starts up, it tries to fire up a bunch of programs that it expects. I have added those to the path and I've tested this by using the sun jvm and achieved the same score of the official gump run. This tells me that the gump installation is sane. Now, the only change between the sun gump run and the harmony one is a change of where JAVA_HOME points to and I wanted to see what happened. In a perfect world, the score of the harmony gump run would have been exactly the same as the score on the sun gump run. This is an indication that the behavior of harmony is different. So far it's different in two aspects: 1) there is no javac process in the JAVA_HOME/bin and the bootstrap-ant module can't work without it 2) running the 'maven' or 'mvn' scripts fails to load the JVM due to linkage problems. So either the those scripts fail to setup some native library-related environment or harmony expects relative paths and might get screwed by embedded execution in other scripts. I've just tried to do export JAVA_HOME=~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/ and call maven, mvn and ant and all result in the same error java/lang/UnsatisfiedLinkError : Failed loading library libhytext.so: DSO load failed so it seems that harmony has a problem being launched inside scripts which is clearly a bug that needs to be fixed.
Re: [jira] Patch available setting
Tim Ellison wrote: Geir Magnusson Jr. wrote: I thought we had it configured that when a JIRA is modified, the reporter is notified directly... I'm not sure that really helps though. I wonder if we should just open things up a bit and let any user modify a JIRA and see what happens. +1 Provided we don't become a spam target, I'm all for letting anyone who has a JIRA account modify an issue. Yes - clearly it requires an account. We'd never leave it open... geir Regards, Tim
Re: [drlvm][em64t] build fails
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 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. geir
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
um... classlib uses SIGUSR2 as well? Doesn't our thread manager use it? Evgueni Brevnov wrote: Hey, Seems like the pretty old problem shows itself again. I'm talking about SIGUSR2 signal :-(...Classlib's asynchronous signal reporter uses system semaphores for synchronization purposes...and hysem_wait is interrupted by the signal: (gdb) p perror(sym_wait error:) sym_wait error:: Interrupted system call Do we have good (universal) solution for such cases? Thanks Evgueni On 11/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Gregory Shimansky wrote: 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 (jokeshall we maybe call this distribution buggy and move on?/joke). There is something odd about it, I'll admit... Remember the EOMEM bugs I found in forking? 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 signal handler called #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.
Re: [jira] Patch available setting
Egor Pasko wrote: On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote: I thought we had it configured that when a JIRA is modified, the reporter is notified directly... I'm not sure that really helps though. I wonder if we should just open things up a bit and let any user modify a JIRA and see what happens. reporters are notified, that's right But what if reporter=patch publisher? Then someone still needs to review. Sometimes, reporters are not familiar with the components fixed, someone needs to pick up a review in this case too. That's why I watch things I'm interested in. I just look at all Harmony JIRA notifications. There are a lot, but most can be safely skipped by subject. Right - do a watch on the JIRAs you are interested in - they come to you directly, not to the project JIRA stream. geir geir Sian January wrote: Hi, I have just discovered that it's not possible for a contributor to set Patch available on a JIRA unless they reported it. (I'm not sure about committers as I'm not one...) I imagine this is to stop people coming in and editing other details on the JIRA, so I can see that it makes sense. My question is, what is the best thing to do if I attach a patch to a JIRA and I can't set Patch available? I can think of three alternatives at the moment: 1. Assume that the reporter will notice and set it themselves (or commit the fix if they're also a comitter) 2. E-mail the reporter privately 3. Post to the mailing list Or a fourth alternative would be a combination of the above where the person who contributed the patch waits a few days before doing either 2 or 3. Any thoughts on what would be best? Thanks, Sian
Re: [drlvm][em64t] build fails
Pavel Afremov wrote: On 11/15/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: How could there be no limit to stack size?? Limit is there but it's too large, like 2 in power 46. Is there a way the test framework could set this? Does DRLVM support -Xss yet? No, DRLVM doesn't support –Xss flag. …yet. I have a question: Is Xss flag significant feature or there are more important things? Probably more important things... but... I would think that -Xss would be pretty simple? I think that the solution is (as I noted in another message) is to somehow set the process stack size w/ ulimit geir Pavel Afremov
Re: [drlvm][em64t] build fails
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'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. geir
Re: svn commit: r475458 - /incubator/harmony/enhanced/admin/README.txt
maybe we should put this in our regular NOTICE file? [EMAIL PROTECTED] wrote: Author: tellison Date: Wed Nov 15 14:11:04 2006 New Revision: 475458 URL: http://svn.apache.org/viewvc?view=revrev=475458 Log: Add readme with explanation of bis export file. Added: incubator/harmony/enhanced/admin/README.txt (with props) Added: incubator/harmony/enhanced/admin/README.txt URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/admin/README.txt?view=autorev=475458 == --- incubator/harmony/enhanced/admin/README.txt (added) +++ incubator/harmony/enhanced/admin/README.txt Wed Nov 15 14:11:04 2006 @@ -0,0 +1,13 @@ +Apache Harmony Export Notification +== + +The file bis_HARMONY.rdf in this directory should not be +moved/renamed since it is referenced directly from the ASF +export registry. + +Details of the export requirements are given here +http://www.apache.org/dev/crypto.html + +The e-mail sent to the US Government is archived here + http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/raw/[EMAIL PROTECTED] + Propchange: incubator/harmony/enhanced/admin/README.txt -- svn:eol-style = native
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
I still think that this is bogus
What if SOE machinery is broken?
We need to make this a predictable test.
[EMAIL PROTECTED] wrote:
Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473
URL: http://svn.apache.org/viewvc?view=revrev=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=diffrev=475473r1=475472r2=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);
}
}
Re: [drlvm][unit] 100% of class library tests pass
Alexei Fedotov wrote: Folks, According to http://harmonytest.org, today 100% of class library unit tests pass on DRLVM. Yay! There are still open issues with reliability, multiprocessor and other special configurations, so the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM remains active. But this shouldn't prevent us from including class library testing into Harmony zero regression policy. What do you think? +1 geir
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
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?
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?
geir
[EMAIL PROTECTED] wrote:
Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473
URL: http://svn.apache.org/viewvc?view=revrev=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=diffrev=475473r1=475472r2=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);
}
}
Re: [drlvm][unit] 100% of class library tests pass
Be sure to not miss anyone :) This was a great community effort, with everyone pitching in. DRLVM is now a full peer to J9 in Harmony testing. :) We still need to use J9 (and another VM that happens to work with our classlibrary), as a sanity check, but we should from now on use DRLVM in our CI testing framework. geir Alexei Fedotov wrote: Oops, I've missed: * Andrew Zhang for reviewing class library patches and helpful discussions On 11/16/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Folks, According to http://harmonytest.org, today 100% of class library unit tests pass on DRLVM. Thank you all! It takes 44 days for the great team we are. Thanks for your thoughtful, diligent work and deep inspiration. Kudos to you for the following (and not limited to this): * Alexey Varlamov and Elena for driving the whole process * Anton and Vladimir Ivanov for automating test runs * Geir and Gregory for checking and committing related DRLVM patches * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and committing related class library patches * Alexey Petrenko for becoming ICU expert and writing good JIRA issue resolution guidelines * Alexei Zakharov for resolving class library test issues * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay Sidelnikov and Alexander Astapchuk for making execution engines work * Tatiana and Maxim for filing JIRA issues about test failures * Nikolay Kuznetsov for completing thread interruption handling and reverting consequences of park/unpark integration * Pavel Afremov for fixing exception handling * Boris Kuznetsov for intelligent fixing of security tests * Rana and Salikh for evaluating and discussing problems, reviewing and trying DRLVM patches * Pavel Pervov and Evgueni for help with DRLVM patches * Artem for discovering and fixing weird Windows* behavior * My wife for bringing hot tea to the computer during sleepless nights There are still open issues with reliability, multiprocessor and other special configurations, so the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM remains active. But this shouldn't prevent us from including class library testing into Harmony zero regression policy. What do you think? -- Thank you, Alexei
Re: [Fwd: Re: [x86_64] problem running DRLVM]
Gregory Shimansky wrote: On Thursday 16 November 2006 02:28 Geir Magnusson Jr. wrote: I think I said I was going to look at it... An FYI - it's demotivating for people that say they'll do something to have someone else race and beat them to it... I'm not mad, but wanted to let you know. I considered these to be two separate problems. One is that launcher crashes in case of no arguments, another is when drlvm throws UnsatisfiedLinkError which means that it is actually running, in which case newPathToAdd should be initialized in the launcher (but is probably initialized in a wrong way). Ah I did not try to fix the second problem, I don't even know how to reproduce it because for me drlvm doesn't give these problems and I don't have gump installed to try to see what's happening when it is running in gump environment. Original Message Subject: Re: [x86_64] problem running DRLVM Date: Thu, 16 Nov 2006 02:16:10 +0300 From: Gregory Shimansky Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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. scratch-head/ 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.
Re: [Fwd: Re: [x86_64] problem running DRLVM]
sorry Gregory Shimansky wrote: On Thursday 16 November 2006 02:28 Geir Magnusson Jr. wrote: I think I said I was going to look at it... An FYI - it's demotivating for people that say they'll do something to have someone else race and beat them to it... I'm not mad, but wanted to let you know. I considered these to be two separate problems. One is that launcher crashes in case of no arguments, another is when drlvm throws UnsatisfiedLinkError which means that it is actually running, in which case newPathToAdd should be initialized in the launcher (but is probably initialized in a wrong way). I did not try to fix the second problem, I don't even know how to reproduce it because for me drlvm doesn't give these problems and I don't have gump installed to try to see what's happening when it is running in gump environment. Original Message Subject: Re: [x86_64] problem running DRLVM Date: Thu, 16 Nov 2006 02:16:10 +0300 From: Gregory Shimansky Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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. scratch-head/ 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.
Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Gregory Shimansky wrote: 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. I think that we learned that depending on the default is dangerous. Try ulimit -s unlimited :) 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. So maybe we should ensure that we can do something that can't be optimized away... 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
Re: [Fwd: Re: [x86_64] problem running DRLVM]
My bad. Sorry again. Please ignore. geir Geir Magnusson Jr. wrote: sorry Gregory Shimansky wrote: On Thursday 16 November 2006 02:28 Geir Magnusson Jr. wrote: I think I said I was going to look at it... An FYI - it's demotivating for people that say they'll do something to have someone else race and beat them to it... I'm not mad, but wanted to let you know. I considered these to be two separate problems. One is that launcher crashes in case of no arguments, another is when drlvm throws UnsatisfiedLinkError which means that it is actually running, in which case newPathToAdd should be initialized in the launcher (but is probably initialized in a wrong way). I did not try to fix the second problem, I don't even know how to reproduce it because for me drlvm doesn't give these problems and I don't have gump installed to try to see what's happening when it is running in gump environment. Original Message Subject: Re: [x86_64] problem running DRLVM Date: Thu, 16 Nov 2006 02:16:10 +0300 From: Gregory Shimansky Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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. scratch-head/ 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.
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
ah. whew.
can you point me to that change you made?
geir
Evgueni Brevnov wrote:
I'm not aware if classlib uses SIGUSR2. In this particular case
classlib (to be more precise it is the portlib module) does sem_wait
which is interrupted by TM's SIGUSR2 signal. I replaced hysem_wait
with while (hysem_wait() != 0) {}. It helped to pass all tests.
Evgueni
On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
um... classlib uses SIGUSR2 as well? Doesn't our thread manager use it?
Evgueni Brevnov wrote:
Hey,
Seems like the pretty old problem shows itself again. I'm talking
about SIGUSR2 signal :-(...Classlib's asynchronous signal reporter
uses system semaphores for synchronization purposes...and hysem_wait
is interrupted by the signal:
(gdb) p perror(sym_wait error:)
sym_wait error:: Interrupted system call
Do we have good (universal) solution for such cases?
Thanks
Evgueni
On 11/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Gregory Shimansky wrote:
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 (jokeshall we maybe call this
distribution buggy and move on?/joke).
There is something odd about it, I'll admit... Remember the EOMEM
bugs
I found in forking?
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 signal handler called
#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
[general] TLP transition - site has been moved, redirect in place
We now have a site http://harmony.apache.org/ and there's a redirect from http://incubator.apache.org/harmony/ to there. Tomorrow sometime we'll do the mail switch - that should be totally transparent - new lists will be created, sub lists will be copied, and mail going to old will be forwarded to new. I'll have the website setup before hand, do the switch, and then update the site. Also, Friday night eastern we'll do the SVN switch to avoid catching people in the middle of work (ok, some will still be caught...). A simple svn switch will fix your local copy, so you shouldn't have to re-check anything out. JIRA has been re-categorized, and I'll be asking for a solaris zone to play in.
[build-test] Moving from /enhanced to /standard
Does anyone care? This way, we can be freer about who and what goes in there. Since we don't ship the testing frameworks with anything, this is completely consistent with our IP policies and goals. geir
Re: [drlvm][unit] 100% of class library tests pass
Pavel Ozhdikhin wrote: On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Be sure to not miss anyone :) This was a great community effort, with everyone pitching in. DRLVM is now a full peer to J9 in Harmony testing. :) We still need to use J9 (and another VM that happens to work with our classlibrary), as a sanity check, but we should from now on use DRLVM in our CI testing framework. On the other hand, to make sure DRLVM has no regressions regarding to Classlibrary Unit Tests it makes sense to add these tests to the test target of DRLVM build. What do people think? Adding classlib unit tests to DRLVM test target? No thanks :) geir Thanks, Pavel geir Alexei Fedotov wrote: Oops, I've missed: * Andrew Zhang for reviewing class library patches and helpful discussions On 11/16/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Folks, According to http://harmonytest.org, today 100% of class library unit tests pass on DRLVM. Thank you all! It takes 44 days for the great team we are. Thanks for your thoughtful, diligent work and deep inspiration. Kudos to you for the following (and not limited to this): * Alexey Varlamov and Elena for driving the whole process * Anton and Vladimir Ivanov for automating test runs * Geir and Gregory for checking and committing related DRLVM patches * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and committing related class library patches * Alexey Petrenko for becoming ICU expert and writing good JIRA issue resolution guidelines * Alexei Zakharov for resolving class library test issues * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay Sidelnikov and Alexander Astapchuk for making execution engines work * Tatiana and Maxim for filing JIRA issues about test failures * Nikolay Kuznetsov for completing thread interruption handling and reverting consequences of park/unpark integration * Pavel Afremov for fixing exception handling * Boris Kuznetsov for intelligent fixing of security tests * Rana and Salikh for evaluating and discussing problems, reviewing and trying DRLVM patches * Pavel Pervov and Evgueni for help with DRLVM patches * Artem for discovering and fixing weird Windows* behavior * My wife for bringing hot tea to the computer during sleepless nights There are still open issues with reliability, multiprocessor and other special configurations, so the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM remains active. But this shouldn't prevent us from including class library testing into Harmony zero regression policy. What do you think? -- Thank you, Alexei
Re: [general] TLP transition - site has been moved, redirect in place
I'm doing that as we, er, speak. geir Mikhail Loenko wrote: Seems like Harmony disappeared from the incubator page but hasn't yet appeared on the apache.org page 2006/11/16, Geir Magnusson Jr. [EMAIL PROTECTED]: We now have a site http://harmony.apache.org/ and there's a redirect from http://incubator.apache.org/harmony/ to there. Tomorrow sometime we'll do the mail switch - that should be totally transparent - new lists will be created, sub lists will be copied, and mail going to old will be forwarded to new. I'll have the website setup before hand, do the switch, and then update the site. Also, Friday night eastern we'll do the SVN switch to avoid catching people in the middle of work (ok, some will still be caught...). A simple svn switch will fix your local copy, so you shouldn't have to re-check anything out. JIRA has been re-categorized, and I'll be asking for a solaris zone to play in.
Re: [general] TLP transition - site has been moved, redirect in place
done. will take a little while to propagate from stage to production... geir Geir Magnusson Jr. wrote: I'm doing that as we, er, speak. geir Mikhail Loenko wrote: Seems like Harmony disappeared from the incubator page but hasn't yet appeared on the apache.org page 2006/11/16, Geir Magnusson Jr. [EMAIL PROTECTED]: We now have a site http://harmony.apache.org/ and there's a redirect from http://incubator.apache.org/harmony/ to there. Tomorrow sometime we'll do the mail switch - that should be totally transparent - new lists will be created, sub lists will be copied, and mail going to old will be forwarded to new. I'll have the website setup before hand, do the switch, and then update the site. Also, Friday night eastern we'll do the SVN switch to avoid catching people in the middle of work (ok, some will still be caught...). A simple svn switch will fix your local copy, so you shouldn't have to re-check anything out. JIRA has been re-categorized, and I'll be asking for a solaris zone to play in.
Re: [general] TLP transition - site has been moved, redirect in place
Jimmy, Jing Lv wrote: Geir Magnusson Jr. wrote: We now have a site http://harmony.apache.org/ and there's a redirect from http://incubator.apache.org/harmony/ to there. Tomorrow sometime we'll do the mail switch - that should be totally transparent - new lists will be created, sub lists will be copied, and mail going to old will be forwarded to new. I'll have the website setup before hand, do the switch, and then update the site. Also, Friday night eastern we'll do the SVN switch to avoid catching people in the middle of work (ok, some will still be caught...). A simple svn switch will fix your local copy, so you shouldn't have to re-check anything out. JIRA has been re-categorized, and I'll be asking for a solaris zone to play in. I've found the new page, great! ;) And do we have to change the mail address harmony-dev@incubator.apache.org to [EMAIL PROTECTED] or so tomorrow? Yes - when we make the change, you'll start seeing mail coming from [EMAIL PROTECTED] with reply-to set correctly. You wont' have to resubscribe or anything. We'll modify the site info on mail lists as appropriate at that time. geir
Re: [general] TLP transition - site has been moved, redirect in place
it's on it's way - it needs to propogate from minotaur, the staging server, to the production server. it's automatic on some schedule I don't actually remember... Spark Shen wrote: Jimmy, Jing Lv 写道: Geir Magnusson Jr. wrote: We now have a site http://harmony.apache.org/ and there's a redirect from http://incubator.apache.org/harmony/ to there. Tomorrow sometime we'll do the mail switch - that should be totally transparent - new lists will be created, sub lists will be copied, and mail going to old will be forwarded to new. I'll have the website setup before hand, do the switch, and then update the site. Also, Friday night eastern we'll do the SVN switch to avoid catching people in the middle of work (ok, some will still be caught...). A simple svn switch will fix your local copy, so you shouldn't have to re-check anything out. JIRA has been re-categorized, and I'll be asking for a solaris zone to play in. I've found the new page, great! ;) But still lacks of link on apahce from page. And do we have to change the mail address harmony-dev@incubator.apache.org to [EMAIL PROTECTED] or so tomorrow?
Re: [doc][drlvm] The document Getting started with DRL is outdated
Tim Ellison wrote: Egor Pasko wrote: BTW, I asked my dad to look at the website. Ideas for improvement from him: snip This is loverly -- kudos to you. When I asked my mum about class unloading support she just said 'what?' Well, my grandmother felt that it was a bug in the GC, and should be fixed. Then she went back to her knitting - she's making a sweater that has the JIT-GC interface on it geir
Re: [doc][drlvm] The document Getting started with DRL is outdated
It's hard for all of us. Better to be safe than sorry. The doc content should include the license header in comment, and there is a clear (c) at the bottom. The license header refers to the NOTICE file. Thanks for being conservative about this - it keeps us from getting into trouble. (I was just giggling about the Database reference...) geir Morozova, Nadezhda wrote: Ok, thanks. I somehow feel dumb with anything that deals with legal - copyrights, contracts, licenses...oh! I'd erase all excess disclaimers from our website with pleasure :) Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:45 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated Additional terms from the Database ? LOL Just get rid of it all. Those terms are in our notice file, and that's enough. Unicode didn't put them there, anyway. geir Morozova, Nadezhda wrote: http://incubator.apache.org/harmony/subcomponents/drlvm/getting_started. html#Disclaimer http://incubator.apache.org/harmony/subcomponents/drlvm/developers_guide .html - these seem to have apache and intel copyright (can be resolved) + the Unicode disclaimer. Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated what's the link we're talking about? Morozova, Nadezhda wrote: What about the portions of the Unicode copyright? Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated as an intel person, you can remove an intel copyright. if it's an ASF copyright, you can remove that too from the document (it should be auto-generated at the bottom anyway) geir Egor Pasko wrote: On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova
Re: [doc] site.css
Ivanov, Alexey A wrote: Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. yes, that looks better. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white-space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? I think that since I don't have the first clue about css, and don't intend do it, you can choose :) That said, I think that spaces are the right way - it's consistent w/ our other source formatting policies. geir Thank you in advance, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Gregory Shimansky wrote: 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 select 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? Hey, the work is done :) The fact is, you can still have a dependency in init and setup to get the goodness from there. I hope to look at this on the plane home tonight. 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. We decided that last may, didn't we? geir
Re: [drlvm][em64t] build fails
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?? Is there a way the test framework could set this? Does DRLVM support -Xss yet? geir
Re: [drlvm][em64t] build fails
Mika Miettinen 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. Sorry for butting into the conversation here, but does this problem have something to do with trying to compile on 64-bit linux especially? Thanks for butting in :) Because I am getting this same error when I try to compile on 64-bit Gentoo on my AMD Athlon 64. But everything goes smoothly when compiling on 32-bit Ubuntu on this same computer. Sorry if I'm stating something obvious, just wanted to know. Mika Miettinen
Re: [drlvm] drlvm and gdb and shared libraries
If that was incorrectly set, they wouldn't load.. that's not the problem Alexei Fedotov wrote: Let me point out the second section of Egor's manual - LD_LIBRARY_PATH is the only thing which should be additionally configured. On 13 Nov 2006 15:46:44 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x220 day of Apache Harmony Geir Magnusson, Jr. wrote: I have a dumb question - I was playing today with a toy launcher for DRLVM working out some embedding issues, and for the life of me, I couldn't get dgb to ever let me break on anything in a shared library. I loaded the vm via dlopen() an dlsym(), and the code runs fine. But even build in debug, I couldn't ever specify a breakpoint in a shared lib even after it was loaded. has anyone run across this? you cannot enable a breakpoint until the library is loaded. Just wait until it is loaded. I wrote [1] to help with that. Hope it helps :) [1] http://wiki.apache.org/harmony/Debugging%20DRLVM%20with%20GDB%20on%20Linux -- Egor Pasko
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Gregory Shimansky wrote: 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 (jokeshall we maybe call this distribution buggy and move on?/joke). There is something odd about it, I'll admit... Remember the EOMEM bugs I found in forking? 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 signal handler called #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.
Re: [jira] Patch available setting
I thought we had it configured that when a JIRA is modified, the reporter is notified directly... I'm not sure that really helps though. I wonder if we should just open things up a bit and let any user modify a JIRA and see what happens. geir Sian January wrote: Hi, I have just discovered that it's not possible for a contributor to set Patch available on a JIRA unless they reported it. (I'm not sure about committers as I'm not one...) I imagine this is to stop people coming in and editing other details on the JIRA, so I can see that it makes sense. My question is, what is the best thing to do if I attach a patch to a JIRA and I can't set Patch available? I can think of three alternatives at the moment: 1. Assume that the reporter will notice and set it themselves (or commit the fix if they're also a comitter) 2. E-mail the reporter privately 3. Post to the mailing list Or a fourth alternative would be a combination of the above where the person who contributed the patch waits a few days before doing either 2 or 3. Any thoughts on what would be best? Thanks, Sian
Re: Deleted version_svn_tag.h
Salikh Zakirov wrote: Nathan Beyer wrote: Not using SVN directly? Do I even want to ask? We have a running SVN-Git mirroring via tailor, and some people prefer to use Git for managing patches, because git 1) is faster 2) can manage many patches and branches 3) can work offline. (I do not intend this as hidden advertisment, sorry if it sounds like it). It doesn't matter. We use SVN :) In any case, I tested it after I deleted the file and the file was regenerated during the build. Did I miss something? I thought this bit was already in the scripts. Nathan, thanks a lot for you attention! I do not think you missed anything, because it is really due to peculiarities in our setup. When SVN information is not available, pointless file copying wasn't performed, and this was also feature requested by me (to shorten recompilation time). Since the fix was committed promptly, I really don't see much problem in this particular case, and do not see anything that you need to change in your process. Yah - nothing has to change. There's nothing to see here. :) geir Thanks for the care, anyway.
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.
Bleah. This can't be the final solution to this...
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?
Re: [x86_64] problem running DRLVM
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. scratch-head/ you mean I'm the first one to run the launcher without parameters... bizarre. On 64-bit? :) Probably. geir ok, now on to trying gump :-)
Re: [x86_64] builds! now onto the tests
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. I'm happy to go with convention, but always worried about uncertainty and randomness. Remember Armand's problems due to a the threading library? geir
Re: Japitools 0.9.7 released
Congratulations! Nice work! geir (I heart Japitools) Stuart Ballard wrote: I'm thrilled to be able to announce four things: 1) After far too long a wait, Japitools 0.9.7 Life, liberty[1] and the pursuit of Japiness has been released. This release includes the following improvements over 0.9.5: - Almost complete 1.5 language support, including generics, enums and varargs methods. The only missing feature for full language support (and the only blocker for a 1.0 release) is annotations. Big thanks to Jeroen Frijters for doing the heavy lifting of teaching Japitools to parse these features in .class files. - The ability to mark methods as not implemented by adding NotImplementedException to the throws clause. This allows Japitools to give results that more accurately match reality when parts of an API are known to have been stubbed out rather than actually being implemented. - The ability to traverse packages non-recursively (thanks to a contribution from Jaroslav Tuloch), making it easier to correctly specify the packages that are part of a public API, especially when that API is large. The new japiextractpkgs tool allows the list of packages to be extracted from Javadoc documentation. - An Ant task for running Japitools, thanks again to Jaroslav. - Too many bug fixes and minor enhancements to name, including a lot of changes that eliminate false positives and false negatives from the results. Thanks to many people for bug reports, feature suggestions and help in testing. 2) That there is now a Japitools mailing list, [EMAIL PROTECTED] See the mailing lists page (http://sab39.netreach.com/Software/Japitools/Mailing_Lists/52/) for more information. 3) That Japitools has a new homepage, http://sab39.netreach.com/japi/. It's ugly, and it's still a work in progress - some sections are still missing content, and others still have content that hasn't entirely been updated to match the current state of reality. I didn't want to delay any further getting the new release into people's hands. I'll continue working on filling out the content. 4) That Sun are AWESOME today! Stuart. [1] https://openjdk.dev.java.net/
Re: [general] Sun will take GPL License?
Jin Mingjian wrote: But does Apache License make JDK out of control? I don't think so:) I think that it just means that it helps them limit the number of proprietary forks of the code. But I'm not worried about that being harmful no matter what the license - the market doesn't want broken Java. geir 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [general] Sun will take GPL License?
It's actually Sun's trademark, not the JCPs. And I don't like the GPL - but that's ok, because there are choices for people. Apache Harmony or Sun's OpenJDK project. geir Jin Mingjian wrote: Java is still the trademark of Sun:) So I think we can do control though JCP. BTW, I like GPL as well:) Whatever, this is big step for Java community. 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: But does Apache License make JDK out of control? I don't think so:) I think that it just means that it helps them limit the number of proprietary forks of the code. But I'm not worried about that being harmful no matter what the license - the market doesn't want broken Java. geir 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: Deleted version_svn_tag.h
Patch applied - please test Salikh Zakirov wrote: Nathan Beyer wrote: I deleted the file and added it to the ignore property. For those of us poor souls not using SVN directly this deletion broke the build, as the file version_svn_tag.h is not available directly now. The issue HARMONY-2168 provides a fix: copy the file.
