RE: [drlvm] [launcher] Executable hangs
There are clean sources unzipped at drlvm\build\pre-copied\lnx\APR\apr-1.2.6\ and (slighly) patched ones (actually used by VM build) at drlvm\build\lnx_ia32_gcc_debug\semis\extra\apr\src\ See README.dev in those location on how to run tests. Or - just a wild thought - hack drlvm\build\make\components\extra\apr.xml to add exec for make test... If you want to generate test coverage data, use the following steps: 1) ./buildconf 2) CFLAGS=-fprofile-arcs -ftest-coverage ./configure 3) make 4) cd test 5) make 6) ./testall 7) cd .. 8) make gcov I took the above steps and on step 5, where it is making the tests in the test directory, I get the following: [EMAIL PROTECTED] /scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semis /extra/apr/src/test $ make make[1]: Entering directory `/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semi s/extra/apr/src/test' /bin/sh /scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semis /extra/apr/src/libtool --silent --mode=link gcc -pthread -fprofile-arcs -ftest- coverage -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I../include -I./../include -no-install-o testlockperf testlockperf.lo ../libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: testlockperf: hidden symbol `__gcov_flush' in /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcov.a(_gcov.o) is referenced by DSO /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[1]: *** [testlockperf] Error 1 make[1]: Leaving directory `/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semi s/extra/apr/src/test' make: *** [all-recursive] Error 1 Thanks, Armand - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
2006/9/28, Elena Semukhina [EMAIL PROTECTED]: The issue has gone away for me too, false alarm possibly... Unfortunately the alarm was not false. Today I got the same failure: ... [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:212: StackIterator* si_create_from_native(): Assertion `!interpreter_enabled()' failed. [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/lin [junit] Test java.lang.RuntimeTest FAILED (timeout) Therefore we face intermittent crash on interpreter... Elena On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote: I've just repeated kernel.test run today several times on fresh build, and tests pass. It's a very stange crash. Execute JIT stack iterator in interpreter mode.. It's outlandishly. On 28/09/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky [EMAIL PROTECTED]: On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: sob :) Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
Today this crash is reproduced quite stably during build.sh kernel.test. But it always passes if run standalone :( Regarding 1559 patch, I looked through it and found nothing suspicious. The only change to interpreter itself was actually preliminary fix for Harmony-1561. This is not good (1559 has no word about this and now better patch is available), but not critical. 2006/10/2, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/28, Elena Semukhina [EMAIL PROTECTED]: The issue has gone away for me too, false alarm possibly... Unfortunately the alarm was not false. Today I got the same failure: ... [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:212: StackIterator* si_create_from_native(): Assertion `!interpreter_enabled()' failed. [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/lin [junit] Test java.lang.RuntimeTest FAILED (timeout) Therefore we face intermittent crash on interpreter... Elena On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote: I've just repeated kernel.test run today several times on fresh build, and tests pass. It's a very stange crash. Execute JIT stack iterator in interpreter mode.. It's outlandishly. On 28/09/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky [EMAIL PROTECTED]: On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: sob :) Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][jitrino]getting field descriptor in translator
Hi! I'm developing package of multidimensional arrays according to JSR-83 and I want it to be optimized in JIT-compiler. The idea is to eliminate redundant boundchecks in a sort of way already implemented ABCD algorithm eliminates redundant boundchecks in one-dimensional arrays. So I need to implement a special instruction in translator/IRBuilder for multiarray boundcheck. But there's a problem: I need some field descriptors of my class DoubleMultiArray3D to generate operands for the instruction (exactly, the capacities of array). There is a method resolveField in CompilationInterface, but it takes index in constant pool as operand - and I don't know index at that moment. I know just string name of the field. I tried the following: to get pointer to struct Class by methodGetClass function of JavaByteCodeTranslator - Struct Class has pointer to array of fields as member - and then find proper field in array of fields. But this last field pointer turned out to point to uninitialized memory. Such behavior is strange because almost the same code written in Class.cpp file allows working with fields (the same memory is initialized in a proper way). Something fatal happens while returning Class pointer to translator. I'll appreciate any suggestions on how to get field descriptor in translator, if I know the name of field and have pointer to Class. -- Maksim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Test input/output files location
Thanks a lot. P.S. It would be good to add this instruction to conventsion. 2006/9/29, Paulex Yang [EMAIL PROTECTED]: Denis Kishenko wrote: I am going to fix some commented tests from java.awt.geom package. I have several organizational questions before start to do. 1. Where is the best place to put test resource files (golden files)? Testing conventions [1] keep silence about this. There are many such files located near the tests, for example modules\awt\src\test\api\java\common\java\awt\geom\shapes\* modules\awt\src\test\api\java\common\java\awt\shapes\* I cannot find it in the archive, but IIRC, this topic was discussed before, and the conclusion was they should be in the modules\awt\src\test\resources\package structure 2. Where is the best place to put test output files? Now it is modules\awt\bin\test\java\awt\shapes\output modules\awt\bin\test\java\awt\geom\shapes\output If they are used temporarily, they should be removed after the test execution, so IMHO the position is not so significant, but maybe the user temp directory is good place to go. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko 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: [classlib][auth]LoginContext should always invoke the LoginModules?
Hi Stepan, all,
I think the spec. statement: A LoginContext should not be used to
authenticate more than one Subject. was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
The decision was mostly about resources.
Indeed, the spec does not specify behavior of LoginContext.
However, the spec is more or less clear in what should the
Login*Module*-s do in response to login/logout/etc.
It states 'login() saves result ...'. It does not warn with
anything like 'check previous state and clean up resources
from previous successful logins'.
The resource clean up is explicitly for abort() and logout().
I consider RI's behavior is more reasonable.
I would say it's more dangerous.
The invocation of login() on already logged LoginModule-s
may easily produce a resource leak.
Presuming the authentication is normally not a too frequent
task, such a leak would be really hard to discover and hunt.
Just my $0.02.
--
Thanks,
Alex
Stepan Mishura wrote:
On 9/29/06, Paulex Yang wrote:
Hi, all
I'm not a security expert, so please correct me if I miss something. I
found some different behavior of Harmony and RI on
javax.security.auth.login.LoginContext, the testcase[1] shows the
difference.
Actually I tried to create the event sequence like below:
1. create LoginContext with some Subject
2. LoginContext.login() and return successfully
3. Modify Subject's content to make it invalid(one Principal's name
here, maybe passwd/username/servername in more general case)
Hi, Paulex
LoginContext doesn't verify Subject's contents - all requred info is
obtained with callback handler and passed to login modules. And login
modules check whether password/username are valid or not.
4. LoginContext.login() again
In RI, the second login() invocation really tried to invoke the relative
LoginModule.login() and then failed to login with the modified Subject,
but in Harmony, both invocations succeed. I consider RI's behavior is
more reasonable.
After a rough look of LoginContext implementation, I found the cause may
be the Ln. 275
private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}
}
I think the spec. statement: A LoginContext should not be used to
authenticate more than one Subject. was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
But if RI let LoginContext object to be reusable then it makes sense doing
the same.
Thanks,
Stepan.
Seems Harmony won't invoke the LoginModule.login() again only if the
login ever succeeds. If I comment out these lines, the test below passes
happily. Any ideas on this issue?
[1]
public class LoginContextTest extends TestCase {
private static final String VALID_NAME = name1;
private static final String INVALID_NAME = name2;
public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new
HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext(moduleName, sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail(Should throw LoginException);
}catch(LoginException e){
}
}
static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
AppConfigurationEntry[]{new
AppConfigurationEntry(MyModule.class.getName(),
LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
MapString, ? arg2, MapString, ? arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
}
--
Paulex Yang
China Software Development Lab
IBM
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Test input/output files location
2006/9/29, Paulex Yang [EMAIL PROTECTED]: Denis Kishenko wrote: I am going to fix some commented tests from java.awt.geom package. I have several organizational questions before start to do. 1. Where is the best place to put test resource files (golden files)? Testing conventions [1] keep silence about this. There are many such files located near the tests, for example modules\awt\src\test\api\java\common\java\awt\geom\shapes\* modules\awt\src\test\api\java\common\java\awt\shapes\* I cannot find it in the archive, but IIRC, this topic was discussed before, and the conclusion was they should be in the modules\awt\src\test\resources\package structure 2. Where is the best place to put test output files? Now it is modules\awt\bin\test\java\awt\shapes\output modules\awt\bin\test\java\awt\geom\shapes\output If they are used temporarily, they should be removed after the test execution, so IMHO the position is not so significant, but maybe the user temp directory is good place to go. I think that File.createTempFile and File.deleteOnExit are good here. SY, Alexey -- Alexey A. Petrenko 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 29 September 2006 at 15:26, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Just renaming the thread
On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
today I tries to build and test one module with HDK. It almost works
:). Small instruction to reproduce:
1) checkout trunk -N, make and modules/beans dirs. Note, beans/
build.xml
refers to some staff in the make dir. Also, the luni-kernel and
security-kernel modules should be checkout to hide errors:
trunk\modules\beans\build.xml:80: Excludesfile
trunk\deploy\build\patternsets\luni-kernel.txt not found.
and
C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
trunk\deploy\build\patternsets\security-kernel.txt not found.
2) run something like ant -Dhy.jdk=C:\harmony\hdk\jdk -
Dbuild.module=beans
from the 'trunk' directory to copy patternsets to the deploy dir.
Note, this
command will be failed on the check-dependency task.
3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
4) go to the module dir (modules/beans in my case). That's all:
module ready
to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
actually, the beans.jar in the HDK will be updated. It is OK?
To do in the build system:
- remove dependency on the luni-kernel and security-kernel modules
I assumed that the dependency was on the patternsets (which could
be removed see thread [classlib] Trying to catch patternset errors
earlier) and the stub jars. These should just be part of the HDK.
- add mode to rebuild module without HDK update (?)
add mode to rebuild without JDK update might be simpler[0]? would it
be sufficient? if not, why not? (Some modules do update the hdk but
these are generally files that would not change often - such as C
header files that define an API which should be fairly stable.)
- add mode to run tests with build html-report for each module.
Definitely +1.
- add mode to run all tests from tests.jar over HDK+ updated classes.
- ?
I think we need more than one tests.jar. In fact, I think we need
more than one tests.jar per module since some tests need to be on the
bootclasspath while others do not (and should not). At the moment
it might be necessary to have more since there isn't really a way to
distinguish api/internal tests (this might change if/when we move to
testng).
We also need to ensure that properties.xml is available in the hdk -
for access to the properties and the make macro. (This is already
on my todo list.) I think we should probably create other macros
to simplify the module build.xml files. (For example, share the
compile-tests/run-tests macros that are already defined in crypto, luni,
rmi, security and x-net.) This is also on my todo list.
Also, since we've stated that when a module is change tests should
be run on the module itself and it's immediate dependent modules, we
really need a way to run other modules tests from a module. This will
be interesting due to the complexity of the test setup but might be
slightly easier if the define common macros. This is probably something
to keep in the back of our minds - I wouldn't let it stop us making
progress.
Regards,
Mark.
[0] Start of build would need to do:
if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
and only deploy jdk files in to ${hy.jdk} - I think/hope this is
true already.
thanks, Vladimir
On 9/28/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Good point. +1 from me.
SY, Alexey
2006/9/27, Alexei Zakharov [EMAIL PROTECTED]:
If we plan to use HDK for supporting developers who work on single
module (that is a good idea IMHO) then we definitely need to supply
jar with tests. We may also supply the build file with placeholders
for user classes tests dirs that will be prepended to
classpath/bootclasspath.
Regards,
2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]:
On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
If I recall, the point of the test.jar was to have a pre-
built jar
of
tests in the HDK so that someone could setup the build-test
infra
using the HDK so they could run tests on their platform w/o
having
to
build everything. Good idea.
Yes, you are correct. This idea implemented in the jira 964.
If that's so, then something would
have to be configured to have the classlib test target use
that
jar. All I'm saying is that how we do this is important, as we
don't
want to cause pain for classlib developers who use the HDK for
development support.
Seems, we think about different use cases.
In my case, user can download the HDK for own platform (if we
have
one) run
tests and look on results (also, may be upload it to the harmony
site). Also
it can be used for application run to check 'enable' status.
But if
this
user interested in Harmony development he
Re: [classlib][test] Test input/output files location
On 28 September 2006 at 15:44, Denis Kishenko [EMAIL PROTECTED] wrote: I am going to fix some commented tests from java.awt.geom package. I have several organizational questions before start to do. 1. Where is the best place to put test resource files (golden files)? Testing conventions [1] keep silence about this. There are many such files located near the tests, for example modules\awt\src\test\api\java\common\java\awt\geom\shapes\* modules\awt\src\test\api\java\common\java\awt\shapes\* As someone else said, these should be in the parallel resources tree. At build time, they should be copied to modules\awt\bin\test so that they can be located at run time using the classpath. (This will allow them to be packaged as a jar of tests.) 2. Where is the best place to put test output files? Now it is modules\awt\bin\test\java\awt\shapes\output modules\awt\bin\test\java\awt\geom\shapes\output A temp directory - preferably not $HOME as some tests seem to at the moment. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Test input/output files location
Alexey, thanks it will be very useful 2006/10/2, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/29, Paulex Yang [EMAIL PROTECTED]: Denis Kishenko wrote: I am going to fix some commented tests from java.awt.geom package. I have several organizational questions before start to do. 1. Where is the best place to put test resource files (golden files)? Testing conventions [1] keep silence about this. There are many such files located near the tests, for example modules\awt\src\test\api\java\common\java\awt\geom\shapes\* modules\awt\src\test\api\java\common\java\awt\shapes\* I cannot find it in the archive, but IIRC, this topic was discussed before, and the conclusion was they should be in the modules\awt\src\test\resources\package structure 2. Where is the best place to put test output files? Now it is modules\awt\bin\test\java\awt\shapes\output modules\awt\bin\test\java\awt\geom\shapes\output If they are used temporarily, they should be removed after the test execution, so IMHO the position is not so significant, but maybe the user temp directory is good place to go. I think that File.createTempFile and File.deleteOnExit are good here. SY, Alexey -- Alexey A. Petrenko 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] -- Denis M. Kishenko 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: [classlib][build] Improvements to build system
Mark Hindess wrote: On 29 September 2006 at 13:14, Oliver Deakin [EMAIL PROTECTED] wrote: Hi all - Ive been away from the list this week, so sorry if Ive missed a few mails. Ill try and get back to them as soon as possible. In the meantime Ive been thinking about the classlib build system, and spotted a couple of things that Id like to fix/cleanup: 1) Although we can build a specific module with -Dbuild.module, currently we cannot just clean or rebuild a single module. I'd like to be able to run ant -Dbuild.module=luni rebuild and have it clean only the luni java and native binaries and rebuild them. Currently this call results in a total clean of all modules, and then all the native code being rebuilt, but only the java code for luni (so you end up with only luni.jar in lib/boot)! It would also be nice to be able to use the new rebuild-java and rebuild-native targets on a per module basis. 2) In the top level build script we have a number of public and private targets (the private ones are prefixed by a hyphen so that they cannot be run from the command line). However at the modular level the build scripts do not have this separation of external and internal targets, even though it is expected that developers may run these scripts directly. I would like to setup these scripts in the same way as the top level build.xml- with build, build-java, build-native etc. external targets and all others as internal and prefixed with a hyphen. I notice that Mark has done some cleanup of the build scripts under make recently, but I think the modular scripts still require tidying up. Does anyone have any objections to these? Any ideas of other relevant activities I can carry out while Im in there? The other things I was thinking about were: 1) Replacing antcall tasks with task dependencies ok, Ill look out for these and replace them where I can. 2) Moving stuff out of the make/build-java.xml file to a module where there is an obvious module that these files should be associated with. For instance, the ant for moving the ecj.jar really belongs with the tools module - since if you aren't building the tools module you would not need that jar. yup, that sounds right - most of the modules already take care of their dependencies individually, tools should be no different. 3) Fixing the way we build the test support jar too frequently - i.e. the fact that we delete it before we test even if it hasn't changed. 4) Whether we can make make/build-native.xml derive some information from the modules - which ones need calling in which order - rather than hard coding this information Do you have any ideas about how we could do this? We have the added complication of the luni module having two native build targets that need to be called at different stages during the build. I had imagined a system where each module has knowledge of the dependencies for it's native code (luni would have two sets of deps). The top level build.xml would call each module in turn, and if that module finds that it's dependencies have already been built, it will go ahead and compile it's libraries. The top level build.xml would make multiple cycles through the set of modules until all have completed building, or the build has failed. However, I'm not sure this is possible in Ant. Ideas? 5) Modular building and testing with an hdk? Once (1) is complete this should be possible with an HDK placed into the deploy directory. i.e. you should be able to unpack an hdk into the deploy directory, and then build, rebuild and test in a modular fashion using -Dbuild.module. I still have the build target work (described at the bottom of [1]) in my todo list - I think this will be more useful once (1) is finished. Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html As usual, I'm sure I'll find more work when I start looking more closely. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
Trace logging gives some more details: GC enumeration in interpreter stack: 0x0x413ee828 referenced from root = 0x0x52721d4c info = 0 0x0x413ee828 info = 0 0x0x413ee828 is java/lang/Class move 0x0x413ee828 to 0x0x41253d24 info = 1 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 [THIS]: java/lang/Class [METHOD native]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I 0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576 0x0x414e9530 info = -2147480576 0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock move 0x0x414e9530 to 0x0x41253d44 info = -2147480575 [THIS]: java/lang/FinalizerThread$FinalizerWorkLock [METHOD 4 2]: java/lang/Object.wait()V Stack[0] NPE or SOE detected at 0x4114fe18 --- 2006/10/2, Alexey Varlamov [EMAIL PROTECTED]: Today this crash is reproduced quite stably during build.sh kernel.test. But it always passes if run standalone :( Regarding 1559 patch, I looked through it and found nothing suspicious. The only change to interpreter itself was actually preliminary fix for Harmony-1561. This is not good (1559 has no word about this and now better patch is available), but not critical. 2006/10/2, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/28, Elena Semukhina [EMAIL PROTECTED]: The issue has gone away for me too, false alarm possibly... Unfortunately the alarm was not false. Today I got the same failure: ... [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:212: StackIterator* si_create_from_native(): Assertion `!interpreter_enabled()' failed. [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/lin [junit] Test java.lang.RuntimeTest FAILED (timeout) Therefore we face intermittent crash on interpreter... Elena On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote: I've just repeated kernel.test run today several times on fresh build, and tests pass. It's a very stange crash. Execute JIT stack iterator in interpreter mode.. It's outlandishly. On 28/09/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky [EMAIL PROTECTED]: On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: sob :) Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy -- Thanks, Elena - 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 10/2/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 29 September 2006 at 15:26, Geir Magnusson Jr. [EMAIL PROTECTED]
wrote:
Just renaming the thread
On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
today I tries to build and test one module with HDK. It almost works
:). Small instruction to reproduce:
1) checkout trunk -N, make and modules/beans dirs. Note, beans/
build.xml
refers to some staff in the make dir. Also, the luni-kernel and
security-kernel modules should be checkout to hide errors:
trunk\modules\beans\build.xml:80: Excludesfile
trunk\deploy\build\patternsets\luni-kernel.txt not found.
and
C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
trunk\deploy\build\patternsets\security-kernel.txt not found.
2) run something like ant -Dhy.jdk=C:\harmony\hdk\jdk -
Dbuild.module=beans
from the 'trunk' directory to copy patternsets to the deploy dir.
Note, this
command will be failed on the check-dependency task.
3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
4) go to the module dir (modules/beans in my case). That's all:
module ready
to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
actually, the beans.jar in the HDK will be updated. It is OK?
To do in the build system:
- remove dependency on the luni-kernel and security-kernel modules
I assumed that the dependency was on the patternsets (which could
be removed see thread [classlib] Trying to catch patternset errors
earlier) and the stub jars. These should just be part of the HDK.
Yes. According to 'error message' it is patterns.
- add mode to rebuild module without HDK update (?)
add mode to rebuild without JDK update might be simpler[0]? would it
be sufficient? if not, why not? (Some modules do update the hdk but
these are generally files that would not change often - such as C
header files that define an API which should be fairly stable.)
the run 'ant build' from module's dir leads to the message like:
trunk\modules\beans\build.xml:80: Problem creating jar:
trunk\deploy\jdk\jre\lib\boot\beans.jar (The system cannot find the path
specified) (and the archive is probably corrupt but I could not delete it)
If you run ant build -Dhy.hdk=hdk/jdk than modules.jar will be updated
into HDK.
Agree, coping all files from HDK to deploy dir should works fine.
- add mode to run tests with build html-report for each module.
Definitely +1.
- add mode to run all tests from tests.jar over HDK+ updated classes.
- ?
I think we need more than one tests.jar. In fact, I think we need
more than one tests.jar per module since some tests need to be on the
bootclasspath while others do not (and should not). At the moment
it might be necessary to have more since there isn't really a way to
distinguish api/internal tests (this might change if/when we move to
testng).
Almost all API tests can be run through the bootclasspath. May be we just
waiting for something like TestNG (or other solution) and will create one
test.jar for each module?
We also need to ensure that properties.xml is available in the hdk -
for access to the properties and the make macro. (This is already
on my todo list.) I think we should probably create other macros
to simplify the module build.xml files. (For example, share the
compile-tests/run-tests macros that are already defined in crypto, luni,
rmi, security and x-net.) This is also on my todo list.
The 'make' module is not big so it can be checkout together with module. But
it will be more convenient if to work with HDK user will need only HDK +
module.
Also, since we've stated that when a module is change tests should
be run on the module itself and it's immediate dependent modules, we
really need a way to run other modules tests from a module. This will
be interesting due to the complexity of the test setup but might be
slightly easier if the define common macros.
As the first step we can run all tests through the bootclasspath. Seems,
that 4 test.jar for each module are too many.
This is probably something
to keep in the back of our minds - I wouldn't let it stop us making
progress.
If you need a help in the test of your changes - I'm a volunteer :)
thanks, Vladimir
Regards,
Mark.
[0] Start of build would need to do:
if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
and only deploy jdk files in to ${hy.jdk} - I think/hope this is
true already.
thanks, Vladimir
On 9/28/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Good point. +1 from me.
SY, Alexey
2006/9/27, Alexei Zakharov [EMAIL PROTECTED]:
If we plan to use HDK for supporting developers who work on single
module (that is a good idea IMHO) then we definitely need to supply
jar with tests. We may also supply the build file with placeholders
for user classes tests dirs that will be prepended to
classpath/bootclasspath.
Regards,
2006/9/27, Vladimir Ivanov [EMAIL
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Thank you Evgueni On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/29/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 9/29/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Artem, Thank you for your feedback find my inlined. On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote: Evgueni, I got most of your changes, but still disagree with all hythread/jthread interface changes. Could leave interface unchanged. See following possible solutions, that could solve the same problems without interface changes. 1) daemon attribute is a java specific. (Andrey mentioned this already). Could you please move it back. to the jthread layer. It is better to rename hythread_wait_for_all_nondaemon_threads() to jthread_wait_for_all_nondaemon_threads(). Ok, I see no problems to move daemon to java layer. In that case: 1) I will move hythread_wait_for_all_nondaemon_threads() from thread_init.c to one which implements java layer. 2) I will move daemon field from HyThread structure. Agree? Sounds good to me. OK, will do that. 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So let the jthread_create() and others to use JNIEnv (that is passed from java native method). The vm_attach could get old JNI env and create new one for the new thread. The first JNIEnv is created in CreateVM call and could be passed to the first thread at startup. No, no, no. I completely disagree with that!!! Why do you like JNIEnv but JavaVM. Why do you think that passing JavaVM instead of JNIEnv makes TM less modular? I don't see any difference here It seems for me like a big big hack to grab JNIEnv from another thread and pass it to jthread_attach to perform operations in the current thread. TM needs to know JNIEnv, mainly for managing the references to objects, throwing exceptions and calling run() method of a new thread. JNI spec proposes that JNIEnv is valid within the given thread, this is why TM holds the JNIEnv pointer at the moment. This is why TM likes the JNIEnv. Having the JNIEnv, one is able to get JavaVM but not vise versa. This is why TM doesn't like the JavaVM :) I see your point. Only one note this is true for already attached threads... I agree with you that there is a design flaw that the JNIEnv is copied from the parent thread to a child thread during thread creation. I think it could be resolved via vm_attach() hook - with this event, VM might tell the TM what the JNIEnv pointer for new thread should be. I think you did that by extending the vm_attach() call with the JNIEnv** argument. What is not completely clear is, why do you have to pass the JavaVM forth and back, once from VM to TM, and then back from TM to VM again? If you need to know in jthread_attach, which particular VM vm_attach() event is coming from, you could have vm_attach like vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv). I'm a little bit confused.Current thread hasn't been attached yet. So there is no JNIEnv for it yet. How it can be passed as the first parameter to vm_attach()? Then you will be always able to get the JavaVM from the JNIEnv. The only difference is that you are currently doing JNIEnv-JavaVM conversion in the VMThreadManager, but why can't you just do this in vm_attach() without changing the interface of the TM? So far JavaVM really looks like an extra knowledge that TM doesn't have to be aware of. Moreover there is no JNIEnv when main thread attaches to VM. So we should either keep it as is or change original design of TM and attach thread to VM before attaching it to TM. In that case we will have valid JNIEnv which can be passed to jthread_atatch. We need to think over it twice before changing something Right. For jthread_attach, JNIenv needs to be changed from being input parameter to being the output parameter. The way how JNIenv is obtained by TM should be vm_attach() event. OK, JNIEnv is output parameter. And it obtained by vm_attach(). This is exactly like I do in the patch. What I don't understand is how jthread_attach knows to which VM the thread should be attached? Do you suggest calling vm_attach first to create JNIEnv it pass it to jthread_attach? 4) Original classlib hythread do not use hythread_library_t in arguments, It uses following code: hythread_library_t lib = GLOBAL_DATA (default_library); or hythread_library_t library = thread-library; So could you please use the same mechanism and remove
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
On 10/1/06, FaeLLe [EMAIL PROTECTED] wrote: Perhaps he means clone the object to a WeakReference then null the original object ? That way the only existing copy of that object will be a WeakReference with my limited understanding of GC concepts would that no be benificial ? Regards, - Vikram Mohan WeakReference can become null any time. We hold strong reference for a reason. Usually algorithms assume that there is no possibility to loose the object we hold at any arbitrary point. With the conversion, the assumption will fail. If we had a way to re-create the state of given object after we have GC'd him, we could use the WeakReferences. But, anyway, I have serious doubts about any performance gain with the approach for _short_living_ objects. Short living object, AFAIU, is objects which are created, initialized, used, and unused any more. Explicit zeroing of no-longer-used references can be benefitial for GC. This is nothing to do with the WeakReferences. -- Ivan 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: svn commit: r450941 - in /incubator/harmony/enhanced/drlvm/trunk/vm: gc/src/ vmcore/include/ vmcore/src/util/
Geir, it was JIRA 1372. Currently it is marked as closed after these commits. It looks like it doesn't compile due to the same mistake Weldon made after me. To new files was not added to the SVN and only existed in local copy of repository. Please deal with the JIRA, either reopen it or commit it again with the new files added. -- Ivan On 9/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: geirm Date: Thu Sep 28 10:53:54 2006 New Revision: 450941 URL: http://svn.apache.org/viewvc?view=revrev=450941 Log: Rollback of r450918, r450919 (HARMONY-1372 it appears) via : $ svn merge -r 450919:450917 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/trunk Uvm/gc/src/prepare.cpp Uvm/gc/src/gc_for_vm.cpp Uvm/gc/src/init.cpp Uvm/gc/src/collect_forced.cpp Uvm/gc/src/collect_cache.cpp Uvm/gc/src/slide_compact.h Uvm/gc/src/collect_slide_compact.cpp Uvm/gc/src/collect_copy.cpp Uvm/gc/src/selector.cpp Uvm/gc/src/gc_types.h Uvm/gc/src/collect.cpp Uvm/gc/src/timer.h Uvm/gc/src/root_set_cache.h Uvm/gc/src/collect.h Uvm/vmcore/src/util/mem_alloc.cpp because it doesn't build, even after a clean, on this box anyway - Ubuntu 6. We'll investigate after the snapshot is done. Modified: incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_cache.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_copy.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_forced.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_slide_compact.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_for_vm.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_types.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/init.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/prepare.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/root_set_cache.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/selector.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/slide_compact.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/timer.h incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/mem_alloc.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp?view=diffrev=450941r1=450940r2=450941 -- Ivan 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: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
2006/10/2, Alexey Varlamov [EMAIL PROTECTED]: Trace logging gives some more details: GC enumeration in interpreter stack: 0x0x413ee828 referenced from root = 0x0x52721d4c info = 0 0x0x413ee828 info = 0 0x0x413ee828 is java/lang/Class move 0x0x413ee828 to 0x0x41253d24 info = 1 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 [THIS]: java/lang/Class [METHOD native]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I 0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576 0x0x414e9530 info = -2147480576 0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock move 0x0x414e9530 to 0x0x41253d44 info = -2147480575 [THIS]: java/lang/FinalizerThread$FinalizerWorkLock [METHOD 4 2]: java/lang/Object.wait()V Stack[0] NPE or SOE detected at 0x4114fe18 --- I fixed endless looping in HARMONY-1653. And now we need to understand why the SIGSEGV occurs. Is it corrupted stack or smth else? Ivan, could you please look into this? -- Alexey - 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Hi, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Mark Hindess [EMAIL PROTECTED] wrote: I think we need more than one tests.jar. In fact, I think we need more than one tests.jar per module since some tests need to be on the bootclasspath while others do not (and should not). At the moment it might be necessary to have more since there isn't really a way to distinguish api/internal tests (this might change if/when we move to testng). Almost all API tests can be run through the bootclasspath. May be we just waiting for something like TestNG (or other solution) and will create one test.jar for each module? Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) BTW, personally I use custom-made build file to develop with HDK and single-module checkout. Regards, -- Alexei Zakharov, Intel Middleware Product 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 10/2/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) Seems, it is should be evaluated by VM peoples. The vm crash is not good reaction for test failure. thanks, Vladimir BTW, personally I use custom-made build file to develop with HDK and single-module checkout. Regards, -- Alexei Zakharov, Intel Middleware Product 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Agree. In case somebody is interested: org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest (from bootclasspath), harmony-hdk-r450941, WinXP. Crash info: == [junit] An unhandled error (4) has occurred. [junit] HyGeneric_Signal_Number=0004 [junit] ExceptionCode=c005 [junit] ExceptionAddress=0052A340 [junit] ContextFlags=0001003f [junit] Handler1=00401010 [junit] Handler2=11105CE0 [junit] InaccessibleAddress= [junit] EDI= [junit] ESI= [junit] EAX=0013D69C [junit] EBX= [junit] ECX=007129FC [junit] EDX= [junit] EIP=0052A340 [junit] ESP=0013D66C [junit] EBP= [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll [junit] Module_base_address=0051 [junit] Offset_in_DLL=0001a340 [junit] This application has requested the Runtime to terminate it in an unusual way. [junit] Please contact the application's support team for more information. [junit] Test org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest FAILED == Thanks, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) Seems, it is should be evaluated by VM peoples. The vm crash is not good reaction for test failure. thanks, Vladimir BTW, personally I use custom-made build file to develop with HDK and single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][awt] Non bug??? BufferedImage constructor throws different exceptions on RI and Harmony
Hi all
Constructor of BufferedImage throws different exceptions on RI and
Harmony if width or height is negative. Code to reproduce
new BufferedImage(8, -7, type 1-13)
So we have
1-4 IllegalArgumentException both
5-7 RI - NegativeArraySizeException, Harmony - RasterFormatException
8-9 IllegalArgumentException both
10-11 RI - NegativeArraySizeException, Harmony - IllegalArgumentException
12-13 RI - NegativeArraySizeException, Harmony - RasterFormatException
I think this is non-bug difference because of
5-7 and 12-13: As you see from stack trace both implementations call
Raster.createInterleavedRaster(...)
Spec says
Throws:
RasterFormatException - if w or h is less than or equal to zero,
or computing either location.x + w or location.y + h results in
integer overflow
So RI doesn't folow spec while Harmony does.
10-11: For RI the same situation as listed above while Harmony just
has another implementation.
In all cases it's more logical to throw IllegalArgumentException or
RasterFormatException instead of NegativeArraySizeException.
Any comments?
2006/10/2, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] BufferedImage constructor throws different exceptions on RI and
Harmony
Key: HARMONY-1655
URL: http://issues.apache.org/jira/browse/HARMONY-1655
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
Constructor of BufferedImage throws different exceptions on RI and Harmony if
width or height is negative. Type of exception depends on BufferedImage type
parameter. There are 13 different types exist. Results are listed below.
1-4 IllegalArgumentException both
5-7 RI - NegativeArraySizeException, Harmony - RasterFormatException
8-9 IllegalArgumentException both
10-11 RI - NegativeArraySizeException, Harmony - IllegalArgumentException
12-13 RI - NegativeArraySizeException, Harmony - RasterFormatException
I think this is non-bug difference because of
5-7 and 12-13: As you see from stack trace both implementations call
Raster.createInterleavedRaster(...)
Spec says
Throws:
RasterFormatException - if w or h is less than or equal to zero, or
computing either location.x + w or location.y + h results in integer overflow
So RI doesn't folow spec while Harmony does.
10-11: For RI the same situation as listed above while Harmony just has another
implementation and exception order.
In all cases it's more logical to throw IllegalArgumentException or
RasterFormatException instead of NegativeArraySizeException.
=== Test ==
import java.awt.image.*;
public class Test {
public static void main(String[] argv) {
for(int i = 1; i 14; i++) {
try {
System.err.println(i);
new BufferedImage(8, -7, i);
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
=== RI ==
1
java.lang.IllegalArgumentException: Width (8) and height (-7) cannot be = 0
at
java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999)
at java.awt.image.BufferedImage.init(BufferedImage.java:314)
at Test.main(Test.java:8)
2
java.lang.IllegalArgumentException: Width (8) and height (-7) cannot be = 0
at
java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999)
at java.awt.image.BufferedImage.init(BufferedImage.java:323)
at Test.main(Test.java:8)
3
java.lang.IllegalArgumentException: Width (8) and height (-7) cannot be = 0
at
java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999)
at java.awt.image.BufferedImage.init(BufferedImage.java:342)
at Test.main(Test.java:8)
4
java.lang.IllegalArgumentException: Width (8) and height (-7) cannot be = 0
at
java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999)
at java.awt.image.BufferedImage.init(BufferedImage.java:354)
at Test.main(Test.java:8)
5
java.lang.NegativeArraySizeException: Negative size-168
at java.awt.image.DataBufferByte.init(DataBufferByte.java:42)
at java.awt.image.Raster.createInterleavedRaster(Raster.java:253)
at java.awt.image.BufferedImage.init(BufferedImage.java:367)
at Test.main(Test.java:8)
6
java.lang.NegativeArraySizeException: Negative size-224
at java.awt.image.DataBufferByte.init(DataBufferByte.java:42)
at java.awt.image.Raster.createInterleavedRaster(Raster.java:253)
at java.awt.image.BufferedImage.init(BufferedImage.java:382)
at Test.main(Test.java:8)
7
java.lang.NegativeArraySizeException: Negative size-224
at java.awt.image.DataBufferByte.init(DataBufferByte.java:42)
at java.awt.image.Raster.createInterleavedRaster(Raster.java:253)
at java.awt.image.BufferedImage.init(BufferedImage.java:397)
at Test.main(Test.java:8)
8
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
This issue is accompanied now with similar crash on Windows (interpreter): [echo] RUNNING : java.lang.RuntimeTest [junit] This application has requested the Runtime to terminate it in an unu sual way. [junit] Please contact the application's support team for more information. [junit] ...VM Crashed! [junit] Windows reported exception: ACCESS_VIOLATION [junit] Registers: [junit] EAX: 0x, EBX: 0x026084f8, ECX: 0x0f7db83a, EDX=0x000 0 [junit] ESI: 0x0013d180, EDI: 0x1401, ESP: 0x0013d16c, EBP=0x0013d21 8 [junit] EIP: 0x015f6085 [junit] Assertion failed: !interpreter_enabled(), file C:\users\esemukhi\svn \drlvm\trunk\vm\port\src\lil\ia32\pim\stack_iterator_ia32.cpp, line 212 [junit] This application has requested the Runtime to terminate it in an unu sual way. [junit] Please contact the application's support team for more information. [junit] Test java.lang.RuntimeTest FAILED On 10/2/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/2, Alexey Varlamov [EMAIL PROTECTED]: Trace logging gives some more details: GC enumeration in interpreter stack: 0x0x413ee828 referenced from root = 0x0x52721d4c info = 0 0x0x413ee828 info = 0 0x0x413ee828 is java/lang/Class move 0x0x413ee828 to 0x0x41253d24 info = 1 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 [THIS]: java/lang/Class [METHOD native]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I 0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576 0x0x414e9530 info = -2147480576 0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock move 0x0x414e9530 to 0x0x41253d44 info = -2147480575 [THIS]: java/lang/FinalizerThread$FinalizerWorkLock [METHOD 4 2]: java/lang/Object.wait()V Stack[0] NPE or SOE detected at 0x4114fe18 --- I fixed endless looping in HARMONY-1653. And now we need to understand why the SIGSEGV occurs. Is it corrupted stack or smth else? Ivan, could you please look into this? -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Alexei Zakharov wrote: Hi, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Mark Hindess [EMAIL PROTECTED] wrote: I think we need more than one tests.jar. In fact, I think we need more than one tests.jar per module since some tests need to be on the bootclasspath while others do not (and should not). At the moment it might be necessary to have more since there isn't really a way to distinguish api/internal tests (this might change if/when we move to testng). Almost all API tests can be run through the bootclasspath. May be we just waiting for something like TestNG (or other solution) and will create one test.jar for each module? Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) BTW, personally I use custom-made build file to develop with HDK and single-module checkout. Wouldn't this be something nice to show people? :) geir Regards, - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][jmx] Options for going forward w/ MX4J
Thanks for the comments, Simone. I'm hoping that at some point in the near future, we can think about doing other things that bring the communities closer together, but this is a great first step. geir Simone Bordet wrote: Hi, On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: I've been talking with Simone Bordet about how we might bring MX4J into Harmony. I think it's a good code base to build our JMX implementation on, as it's well tested and has been used in implementations that have been tested with the JMX TCK. (We can't say that MX4J passes, as I don't believe the project has a TCK). MX4J has served many people over many years, and it's a shame that the addition of JMX into the SE platform has sent this project into it's golden years. I see it a bit differently -- it is a testament to the quality and broad use of MX4J that has helped make JMX a compelling addition to Java SE. I join you in commending Simone and the other contributors for their work. Thanks for the kind words. There were a lot of issues discussed, mainly about user support, time Simone could commit to help us, etc , and in summary, it boils down to this : Simone has no problem with us doing a gentle fork (in his words) of the code to build on. By this, we are simply taking a snapshot of the project codebase, and building upon it. This is not a hostile, anti-community act, but simply a recognition that it's useful code for us, we want to keep building on the code base, but need to make modifications for java SE 5 that are incompatible with the needs of the pre-Java 5 users that the MX4J project support. I read this as an indication that MX4J has no interest in pursuing a 5.0 compatible implementation? Likewise we have no interest in distributing a 1.4 version. Correct. My take on the issue is that there is no point for MX4J to implement JMX 1.3 (shipped in JDK 5), since it will be very rare that people will put such an alternative implementation in the boot classpath before the JDK classes. I think implementing JMX 1.3 belongs more to an effort such as Harmony, or such as Application Servers heavily based on JMX that support J2EE 5. Presumably all the enhancements that are made in the Harmony SVN tree are 'our new enhancements', so identifying them will not be a problem. Putting the code into standard sounds like the right answer. I assume that in this scenario, and unlike concurrent, we do not attempt to keep the two sites in sync. This is also my thinking. We can agree on a best effort communication where mx4j notifies harmony-dev of bugs discovered in mx4j, or of new releases, and harmony can communicate bugs to mx4j, with the goal of saving time and energy, but not with the goal of keeping the codebases in sync. Regards, Simon - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r450941 - in /incubator/harmony/enhanced/drlvm/trunk/vm: gc/src/ vmcore/include/ vmcore/src/util/
definitely top of my list for this morning. I'm hoping it was nothing more than what you describe. geir Ivan Volosyuk wrote: Geir, it was JIRA 1372. Currently it is marked as closed after these commits. It looks like it doesn't compile due to the same mistake Weldon made after me. To new files was not added to the SVN and only existed in local copy of repository. Please deal with the JIRA, either reopen it or commit it again with the new files added. -- Ivan On 9/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: geirm Date: Thu Sep 28 10:53:54 2006 New Revision: 450941 URL: http://svn.apache.org/viewvc?view=revrev=450941 Log: Rollback of r450918, r450919 (HARMONY-1372 it appears) via : $ svn merge -r 450919:450917 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/trunk Uvm/gc/src/prepare.cpp Uvm/gc/src/gc_for_vm.cpp Uvm/gc/src/init.cpp Uvm/gc/src/collect_forced.cpp Uvm/gc/src/collect_cache.cpp Uvm/gc/src/slide_compact.h Uvm/gc/src/collect_slide_compact.cpp Uvm/gc/src/collect_copy.cpp Uvm/gc/src/selector.cpp Uvm/gc/src/gc_types.h Uvm/gc/src/collect.cpp Uvm/gc/src/timer.h Uvm/gc/src/root_set_cache.h Uvm/gc/src/collect.h Uvm/vmcore/src/util/mem_alloc.cpp because it doesn't build, even after a clean, on this box anyway - Ubuntu 6. We'll investigate after the snapshot is done. Modified: incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_cache.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_copy.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_forced.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect_slide_compact.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_for_vm.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_types.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/init.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/prepare.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/root_set_cache.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/selector.cpp incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/slide_compact.h incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/timer.h incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/mem_alloc.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp?view=diffrev=450941r1=450940r2=450941 - 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 2 October 2006 at 8:52, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I wonder if we can generate some kind of dependency graph as part of the build, so that if testing in a module, it can figure out the set of modules to test that are n-away dependent. (IOW, test module + 1-away because it's quick, then before checkin test module + 2-away [or all]) I wondered about this for a different reason... I think it might be interesting to be able to automate this even in a fairy rough way since I'm interested to see what dependencies we are adding between our modules over time. Since my impression (based on no real evidence) is that we perhaps aren't really giving it much thought. -Mark. - 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] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: Agree. In case somebody is interested: org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest (from bootclasspath), harmony-hdk-r450941, WinXP. Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), JET? Crash info: == [junit] An unhandled error (4) has occurred. [junit] HyGeneric_Signal_Number=0004 [junit] ExceptionCode=c005 [junit] ExceptionAddress=0052A340 [junit] ContextFlags=0001003f [junit] Handler1=00401010 [junit] Handler2=11105CE0 [junit] InaccessibleAddress= [junit] EDI= [junit] ESI= [junit] EAX=0013D69C [junit] EBX= [junit] ECX=007129FC [junit] EDX= [junit] EIP=0052A340 [junit] ESP=0013D66C [junit] EBP= [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll [junit] Module_base_address=0051 [junit] Offset_in_DLL=0001a340 [junit] This application has requested the Runtime to terminate it in an unusual way. [junit] Please contact the application's support team for more information. [junit] Test org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest FAILED == Thanks, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) Seems, it is should be evaluated by VM peoples. The vm crash is not good reaction for test failure. thanks, Vladimir BTW, personally I use custom-made build file to develop with HDK and single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Egor Pasko, Intel Managed Runtime 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: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/30/06, Weldon Washburn [EMAIL PROTECTED] wrote: Good! I look forward to seeing vm helpers written in vmmagic. Yes, this is the final goal and I hope we will start the implementation of VM helpers using magics package this week. The only item left to do is to restore JET support for your experiments with GC. I'm going to commit the patch in a day. Weldon, I finished vmmagic implementation in OPT compiler and there are no known bugs left. I tested the code with Eclipse and several benchmarks - nothing is broken, all applications work OK. Could I ask you to add the 'magics' support code into the trunk? The patch name is 'magic4.diff' in H1489 -- Mikhail Fursov
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: The same result with the -Xem:opt. Could you file a JIRA for that, please? With steps to reproduce. Please, also check with -Xem:jet. Thanks for pointing out failures like that. The exact command in my environment was (WinXP SP2): == C:\mydoc\projects\tests\beans2echo %JAVA_HOME% C:\Java\harmony-hdk-r450941\jdk\jre C:\mydoc\projects\tests\beans2%JAVA_HOME%\bin\java -Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar -Xem:opt junit.textui.TestRunner org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest ... An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=0052A340 ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress= EDI= ESI= EAX=0013F1AC EBX= ECX=007129FC EDX= EIP=0052A340 ESP=0013F17C EBP= Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll Module_base_address=0051 Offset_in_DLL=0001a340 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. == Regards, 02 Oct 2006 20:14:11 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: Agree. In case somebody is interested: org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest (from bootclasspath), harmony-hdk-r450941, WinXP. Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), JET? Crash info: == [junit] An unhandled error (4) has occurred. [junit] HyGeneric_Signal_Number=0004 [junit] ExceptionCode=c005 [junit] ExceptionAddress=0052A340 [junit] ContextFlags=0001003f [junit] Handler1=00401010 [junit] Handler2=11105CE0 [junit] InaccessibleAddress= [junit] EDI= [junit] ESI= [junit] EAX=0013D69C [junit] EBX= [junit] ECX=007129FC [junit] EDX= [junit] EIP=0052A340 [junit] ESP=0013D66C [junit] EBP= [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll [junit] Module_base_address=0051 [junit] Offset_in_DLL=0001a340 [junit] This application has requested the Runtime to terminate it in an unusual way. [junit] Please contact the application's support team for more information. [junit] Test org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest FAILED == Thanks, 2006/10/2, Vladimir Ivanov [EMAIL PROTECTED]: On 10/2/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) Seems, it is should be evaluated by VM peoples. The vm crash is not good reaction for test failure. thanks, Vladimir BTW, personally I use custom-made build file to develop with HDK and single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Egor Pasko, Intel Managed Runtime 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: [classlib] removing \t from sources
What do you mean? Convert \t to something? If so please see the
new fully customized version of my mega-script :-)
The usage pattern in your case will be:
ant -f tabs2spaces_v2.xml -Dsrc.dir=dir with sources -Dpattern= \t
Regards,
2006/10/2, Alexey Petrenko [EMAIL PROTECTED]:
Does it work with the sequences like {space, space, tab} etc?
2006/10/2, Alexei Zakharov [EMAIL PROTECTED]:
Hi all,
I noticed that the tab character (0x09) is still widely used in our
classlib source code. At least in tests. From my recent experience
this leads to broken indentation. I mean the situation when patch with
spaces is applied to the source there tab character is used for
indentation. Someone knows that according to Sun code conventions the
tab should be exactly 8 spaces. The other person knows that exactly
four spaces should be used as the unit of indentation [1]. As a result
we have all methods indented with the single tab character and the
patched methods indented with 4 spaces. And if your IDE is configured
to display tabs as 8 spaces you will see broken indentation. Or vice
versa.
I have created small ANT script - see HARMONY-1660 [2]. This script
converts all tabs to spaces in all found sources under the given
directory recursively. I will be grateful if someone runs this script
(tab - 4 spaces) at least for beans tests (I currently working with)
and integrates the results. It is really painful to deal with this
broken alignment every day. And it is too boring (and IMHO silly) to
convert it file by file and send patches for each case.
[1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
[3] http://issues.apache.org/jira/browse/HARMONY-1660
Thanks,
--
Alexei Zakharov,
Intel Middleware Product 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: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
I have fixed a problem in gc_alloc(), see HARMONY-1661. After that test passes on my computer. -- Ivan On 10/2/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Ok, I will look at the issue today. -- Ivan On 10/2/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/2, Alexey Varlamov [EMAIL PROTECTED]: Trace logging gives some more details: GC enumeration in interpreter stack: 0x0x413ee828 referenced from root = 0x0x52721d4c info = 0 0x0x413ee828 info = 0 0x0x413ee828 is java/lang/Class move 0x0x413ee828 to 0x0x41253d24 info = 1 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 0x(nil) referenced from object = 0x0x41253d24 [THIS]: java/lang/Class [METHOD native]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I 0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576 0x0x414e9530 info = -2147480576 0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock move 0x0x414e9530 to 0x0x41253d44 info = -2147480575 [THIS]: java/lang/FinalizerThread$FinalizerWorkLock [METHOD 4 2]: java/lang/Object.wait()V Stack[0] NPE or SOE detected at 0x4114fe18 --- I fixed endless looping in HARMONY-1653. And now we need to understand why the SIGSEGV occurs. Is it corrupted stack or smth else? Ivan, could you please look into this? -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] apr_dso_load error (path address out of bounds)
I am still having trouble getting hellworld to run. Currently the problem
is that for some reason in dll_jit.cpp on line 62, where the call is made to
apr_dso_load, the second parameter which is the path to the dll becomes
address out of bounds in the apr_dso_load procedure.
Egor suggested that perhaps APR configured itself incorrectly on my system.
Alexey suggested I try to run the APR test. I ran the APR tests and all
tests passed (in /build/lnx_ia32_gcc_debug/semis/extra/apr/src/test).
Below is what happens in gdb. Also below that I have pasted what happens at
the end of the output when I run ./java -Xthread -Xtrace helloworld.
Another thing that is suspicious is that when I run ./java it works fine,
but if I run ./java -Xthread -Xtrace it does not run fine (it hangs inside
GetObjectClass). I have also pasted the end of the trace for this.
Let me know if there is any other debugging information I can provide.
(gdb) r helloworld
Starting program:
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java
helloworld
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 16947)]
[New Thread 32769 (LWP 16950)]
[New Thread 16386 (LWP 16951)]
Breakpoint 2 at 0xb6e28ca5: file
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp
, line 628.
Pending breakpoint vm_main.cpp:628 resolved
[Switching to Thread 16384 (LWP 16947)]
Breakpoint 2, vm_load_jit (file_name=0x80aa83c
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
/libjitrino.so, handle=0xbff4ff4c)
at
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp
:628
628 Dll_JIT* jit = new Dll_JIT(file_name);
Current language: auto; currently c++
(gdb) s
Dll_JIT (this=0x80aa708, dll_filename=0x80aa83c
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
/libjitrino.so)
at
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/jit/dll_jit.cpp:
56
56 {
(gdb) n
59 memset((void *) jit_flags, 0, sizeof(JIT_Flags));
(gdb) n
60 apr_pool_create(pool, 0);
(gdb) n
62 if ((stat = apr_dso_load(handle, dll_filename, pool)) !=
APR_SUCCESS)
(gdb) p dll_filename
$1 = 0x80aa83c
/scratch/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
/libjitrino.so
(gdb) s
apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds,
pool=0x8090c30) at dso.c:139
139 os_handle = dlopen(path, flags);
Current language: auto; currently c
(gdb) p path
$2 = 0x102 Address 0x102 out of bounds
./java -Xthread -Xtrace helloworld
.
[0x4000] : END class prepare, class name = java/lang/Runtime$ShutdownVM
[0x4000] : StartLoading class java/lang/RuntimePermission with loader
0x80be790
[0x8003] : gc_thread_init 0x807e718
[0x8003] : FindClass called, name = java/lang/Thread
[0x8003] : FindClass called, name = java/lang/Thread
[0x8003] : si_goto_previous from ip = (nil) (M2N)
[0x8003] : si_unwind_from_m2n, ip = (nil)
[0x8003] : si_goto_previous to ip = (nil) (M2N)
[0x8003] : StartLoading class java/lang/Thread with loader 0x8633d90
[0x8003] : 0x8633d90 0x807e658 I java/lang/Thread
[0x8003] : Loader U (0x8633d90) loading class: java/lang/Thread...
[0x8003] : enter method java/lang/ClassLoader loadClass
(Ljava/lang/String;)Ljava/lang/Class;
[0x4000] : EM: compile done:[JET_DPGO n=789: OK]
java/lang/Runtime::addShutdownHook(Ljava/lang/Thread;)V
(hangs here)
./java -Xthread -Xtrace
.
[0x4000] : GetObjectClass called
[0x4000] : GetObjectClass: class = [Ljava/lang/Class;
[0x8003] : gc_thread_init 0x807e718
[0x8003] : FindClass called, name = java/lang/Thread
[0x8003] : FindClass called, name = java/lang/Thread
[0x8003] : si_goto_previous from ip = (nil) (M2N)
[0x8003] : si_unwind_from_m2n, ip = (nil)
[0x8003] : si_goto_previous to ip = (nil) (M2N)
[0x8003] : StartLoading class java/lang/Thread with loader 0x8633df0
[0x8003] : 0x8633df0 0x807e658 I java/lang/Thread
[0x8003] : Loader U (0x8633df0) loading class: java/lang/Thread...
[0x8003] : enter method java/lang/ClassLoader loadClass
(Ljava/lang/String;)Ljava/lang/Class;
[0x4000] : GetObjectClass called
Thanks,
Armand
Re: [classlib] Should URLClassLoader convert class names? (See HARMONY-1622)
Tim Ellison wrote: FWIW the version in the IBM VME explicitly converts '/' to '.' in the Main-Class: value before looking up the class. I suggest we support both, IMHO nobody will be relying on it failing with '/'s. Sure, but the question is where. JarRunner or ClassLoader... geir Regards, Tim Geir Magnusson Jr. wrote: Looking at HARMONY-1622, I'm not convinced that we need to change JarRunner in DRLVM, but rather should figure out what the right thing to do is in classlib. The issue is having a MainClass in the manifest contain / : geir/GeirTest versus geir.GeirTest My simple quick test showed that the RI will throw an exception with the / and be ok w/ the . Currently, it's reported in 1622 that o.a.h.a.t.j.u.j.JarOutputStreamTest fails on the / in the main class name. I think that's actually right, if we want to conform to the RI. Right now, though, either J9 does the conversion in it's JarRunner, or internally it's classloader infrastructure is more tolerant. Comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Should URLClassLoader convert class names? (See HARMONY-1622)
Geir Magnusson Jr. wrote: Tim Ellison wrote: FWIW the version in the IBM VME explicitly converts '/' to '.' in the Main-Class: value before looking up the class. I suggest we support both, IMHO nobody will be relying on it failing with '/'s. Sure, but the question is where. JarRunner or ClassLoader... In JarRunner. The ClassLoader spec states that : Binary names Any class name provided as a String parameter to methods in ClassLoader must be a binary name as defined by the Java Language Specification. Examples of valid class names include: java.lang.String javax.swing.JSpinner$DefaultEditor java.security.KeyStore$Builder$FileBuilder$1 java.net.URLClassLoader$3$1 Regards, Tim Geir Magnusson Jr. wrote: Looking at HARMONY-1622, I'm not convinced that we need to change JarRunner in DRLVM, but rather should figure out what the right thing to do is in classlib. The issue is having a MainClass in the manifest contain / : geir/GeirTest versus geir.GeirTest My simple quick test showed that the RI will throw an exception with the / and be ok w/ the . Currently, it's reported in 1622 that o.a.h.a.t.j.u.j.JarOutputStreamTest fails on the / in the main class name. I think that's actually right, if we want to conform to the RI. Right now, though, either J9 does the conversion in it's JarRunner, or internally it's classloader infrastructure is more tolerant. Comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Should URLClassLoader convert class names? (See HARMONY-1622)
Ya know... I looked and looked for that in the classLoader docs... I kept skipping over it for some reason Agreed. Tim Ellison wrote: Geir Magnusson Jr. wrote: Tim Ellison wrote: FWIW the version in the IBM VME explicitly converts '/' to '.' in the Main-Class: value before looking up the class. I suggest we support both, IMHO nobody will be relying on it failing with '/'s. Sure, but the question is where. JarRunner or ClassLoader... In JarRunner. The ClassLoader spec states that : Binary names Any class name provided as a String parameter to methods in ClassLoader must be a binary name as defined by the Java Language Specification. Examples of valid class names include: java.lang.String javax.swing.JSpinner$DefaultEditor java.security.KeyStore$Builder$FileBuilder$1 java.net.URLClassLoader$3$1 Regards, Tim Geir Magnusson Jr. wrote: Looking at HARMONY-1622, I'm not convinced that we need to change JarRunner in DRLVM, but rather should figure out what the right thing to do is in classlib. The issue is having a MainClass in the manifest contain / : geir/GeirTest versus geir.GeirTest My simple quick test showed that the RI will throw an exception with the / and be ok w/ the . Currently, it's reported in 1622 that o.a.h.a.t.j.u.j.JarOutputStreamTest fails on the / in the main class name. I think that's actually right, if we want to conform to the RI. Right now, though, either J9 does the conversion in it's JarRunner, or internally it's classloader infrastructure is more tolerant. Comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Mikhail, I just now committed magic5.diff, H1489. Let me know when the next JIRA is ready. I want your mods committed so that I can resume MMTk integration. Thanks Weldon On 10/2/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I forgot to test the last patch on Linux. Now the build is fixed for Linux too and I attached to the H1489 the new patch: 'magic5.diff' On 10/2/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 9/30/06, Weldon Washburn [EMAIL PROTECTED] wrote: Good! I look forward to seeing vm helpers written in vmmagic. Yes, this is the final goal and I hope we will start the implementation of VM helpers using magics package this week. The only item left to do is to restore JET support for your experiments with GC. I'm going to commit the patch in a day. Weldon, I finished vmmagic implementation in OPT compiler and there are no known bugs left. I tested the code with Eclipse and several benchmarks - nothing is broken, all applications work OK. Could I ask you to add the 'magics' support code into the trunk? The patch name is ' magic4.diff' in H1489 -- Mikhail Fursov -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [general] jre and hdk snapshots posted to general snapshot site
On 10/2/06, Oliver Deakin [EMAIL PROTECTED] wrote: ... Does this sound reasonable? Seems, that everybody thinking about separated test jar for each module (I proposed one jar as first step onlyJ). Now, we should implement this. If you need any help I'm a volunteer. thanks, Vladimir Regards, Oliver We may also supply the build file with placeholders for user classes tests dirs that will be prepended to classpath/bootclasspath. Regards, 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If I recall, the point of the test.jar was to have a pre-built jar of tests in the HDK so that someone could setup the build-test infra using the HDK so they could run tests on their platform w/o having to build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would have to be configured to have the classlib test target use that jar. All I'm saying is that how we do this is important, as we don't want to cause pain for classlib developers who use the HDK for development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir geir Thanks, Vladimir Thanks, Vladimir geir Thanks, Vladimir On 7/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: They are at the regular place http://people.apache.org/dist/incubator/harmony/snapshots I moved all the old classlib snapshots into /old and I'll update the website accordingly. I'll be automating this. Also, lets not make much noise about this for a little while so we can test to make sure there's no major errors. Things seem good. I have a list of more things to fix, but I realized today that I was obsessing over the snapshot contents - it's not a release, and it's good enough. I'd like to ditch both /old and the remaining classlib snapshots, as 1) they are snapshots - history doesn't matter 2) the classlib is now in the HDK, so we just need to adjust the docs to match. I'll do the latter, but wanted to see if anyone has a problem w/ me removing /old and the last classlib snapshot. I'll do this if I don't hear any protest, so either positively acknowledge this action if you support it, dont' do a thing if you support or dont' care, or say why we shouldn't :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OFFTOPIC] [legal] a solution to our licensing issues with classpath
http://www.mysql.com/company/legal/licensing/foss-exception.html So it seems that the GPL is compatible with the Apache License, because MySQL says so, at least for Apache code they want to use, like APR. I assume this means you could take a small snippet of MySQL, and use it as a bridge between GPL code and Apache Licensed code? Of course, their section 2.2 says you still have to redistribute your source. Suppose we then do the same thing independently, but make it a free license - put out some code under the GPL with an exception that is like the MySQL exception, but omits section 2.2 - doesn't force source redistribution of the Apache Licensed work... Run that by your favorite lawyer, but don't tell them I sent you :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][exceptions] unexpected 'VM Crashed!' message
It is definitely fixed in https://issues.apache.org/jira/browse/HARMONY-1582
:-) Evgueni
On 10/3/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
I was sure that everyone know about it (I saw it ~1 week ago) and tries to
fix. Issue http://issues.apache.org/jira/browse/HARMONY-1662 was created.
thanks, Vladimir
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Is that windows specific? I don't see it on linux (I see lots of other
drek we need to clean up...)
Post a JIRA?
geir
Vladimir Ivanov wrote:
Seems, it already discussed some time ago but DLRVM still report 'VM
Crashed' message for any application that throws unhandled exception.
Please, fix it. I'm uncomfortable to see it on each runs.
= test.java
public class test {
public static void main(String[] args) throws Exception {
throw new Exception(Hello);
}
}
Output:
C:\tmp\tmp17C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp .
test
Exception in thread main java.lang.Exception: Hello
at test.main(test.java:3)
C:\tmp\tmp17C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\deploy\jre\bin\java
-Dvm.assert_dialog=false -cp . -showversion test
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 = r452292, (Oct 3 2006), Windows/ia32/msvc 1310, debug build
http://incubator.apache.org/harmony
...VM Crashed!
Windows reported exception: ACCESS_VIOLATION
Registers:
EAX: 0x0674, EBX: 0x00421ee8, ECX: 0x0041df80, EDX=0x0005
ESI: 0x0332ff1c, EDI: 0x0020, ESP: 0x0332ff18, EBP=0x0332ff34
EIP: 0x10005d48
SEH handler: shutdown error...VM Crashed!
Windows reported exception: ACCESS_VIOLATION
Registers:
EAX: 0x, EBX: 0x7c97e4a0, ECX: 0x02b12250, EDX=0x
ESI: 0x0332f928, EDI: 0x0332f9e8, ESP: 0x0332f928, EBP=0x0332f92c
EIP: 0x005eea13
SEH handler: too many shutdown errorsJNI.ExceptionDescribe:
java/lang/Exception:
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][exceptions] unexpected 'VM Crashed!' message
On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
It is definitely fixed in
https://issues.apache.org/jira/browse/HARMONY-1582
:-) Evgueni
So I correct remember that it is already discussed :) but was not integrated
yet.
Vladimir
On 10/3/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
I was sure that everyone know about it (I saw it ~1 week ago) and tries
to
fix. Issue http://issues.apache.org/jira/browse/HARMONY-1662 was
created.
thanks, Vladimir
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Is that windows specific? I don't see it on linux (I see lots of
other
drek we need to clean up...)
Post a JIRA?
geir
Vladimir Ivanov wrote:
Seems, it already discussed some time ago but DLRVM still report 'VM
Crashed' message for any application that throws unhandled
exception.
Please, fix it. I'm uncomfortable to see it on each runs.
= test.java
public class test {
public static void main(String[] args) throws Exception {
throw new Exception(Hello);
}
}
Output:
C:\tmp\tmp17C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp
.
test
Exception in thread main java.lang.Exception: Hello
at test.main(test.java:3)
C:\tmp\tmp17C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\deploy\jre\bin\java
-Dvm.assert_dialog=false -cp . -showversion test
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 = r452292, (Oct 3 2006), Windows/ia32/msvc 1310, debug build
http://incubator.apache.org/harmony
...VM Crashed!
Windows reported exception: ACCESS_VIOLATION
Registers:
EAX: 0x0674, EBX: 0x00421ee8, ECX: 0x0041df80, EDX=0x0005
ESI: 0x0332ff1c, EDI: 0x0020, ESP: 0x0332ff18, EBP=0x0332ff34
EIP: 0x10005d48
SEH handler: shutdown error...VM Crashed!
Windows reported exception: ACCESS_VIOLATION
Registers:
EAX: 0x, EBX: 0x7c97e4a0, ECX: 0x02b12250, EDX=0x
ESI: 0x0332f928, EDI: 0x0332f9e8, ESP: 0x0332f928, EBP=0x0332f92c
EIP: 0x005eea13
SEH handler: too many shutdown errorsJNI.ExceptionDescribe:
java/lang/Exception:
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Improvements to build system
Guys, I have a kind request for test target customization: 1) need ability to pass extra arguments to tested jre. This is useful for testing various configurations of VM, e.g. different execution engines in DRLVM. 2) easy switching between fork modes perTest once. This is actual for testing unstable VMs. Or I'm just not aware of smth? Hmm, seems we can use harmonyvm.properties to workaround item 1) ... -- Alexey 2006/10/2, Oliver Deakin [EMAIL PROTECTED]: Mark Hindess wrote: On 29 September 2006 at 13:14, Oliver Deakin [EMAIL PROTECTED] wrote: Hi all - Ive been away from the list this week, so sorry if Ive missed a few mails. Ill try and get back to them as soon as possible. In the meantime Ive been thinking about the classlib build system, and spotted a couple of things that Id like to fix/cleanup: 1) Although we can build a specific module with -Dbuild.module, currently we cannot just clean or rebuild a single module. I'd like to be able to run ant -Dbuild.module=luni rebuild and have it clean only the luni java and native binaries and rebuild them. Currently this call results in a total clean of all modules, and then all the native code being rebuilt, but only the java code for luni (so you end up with only luni.jar in lib/boot)! It would also be nice to be able to use the new rebuild-java and rebuild-native targets on a per module basis. 2) In the top level build script we have a number of public and private targets (the private ones are prefixed by a hyphen so that they cannot be run from the command line). However at the modular level the build scripts do not have this separation of external and internal targets, even though it is expected that developers may run these scripts directly. I would like to setup these scripts in the same way as the top level build.xml- with build, build-java, build-native etc. external targets and all others as internal and prefixed with a hyphen. I notice that Mark has done some cleanup of the build scripts under make recently, but I think the modular scripts still require tidying up. Does anyone have any objections to these? Any ideas of other relevant activities I can carry out while Im in there? The other things I was thinking about were: 1) Replacing antcall tasks with task dependencies ok, Ill look out for these and replace them where I can. 2) Moving stuff out of the make/build-java.xml file to a module where there is an obvious module that these files should be associated with. For instance, the ant for moving the ecj.jar really belongs with the tools module - since if you aren't building the tools module you would not need that jar. yup, that sounds right - most of the modules already take care of their dependencies individually, tools should be no different. 3) Fixing the way we build the test support jar too frequently - i.e. the fact that we delete it before we test even if it hasn't changed. 4) Whether we can make make/build-native.xml derive some information from the modules - which ones need calling in which order - rather than hard coding this information Do you have any ideas about how we could do this? We have the added complication of the luni module having two native build targets that need to be called at different stages during the build. I had imagined a system where each module has knowledge of the dependencies for it's native code (luni would have two sets of deps). The top level build.xml would call each module in turn, and if that module finds that it's dependencies have already been built, it will go ahead and compile it's libraries. The top level build.xml would make multiple cycles through the set of modules until all have completed building, or the build has failed. However, I'm not sure this is possible in Ant. Ideas? 5) Modular building and testing with an hdk? Once (1) is complete this should be possible with an HDK placed into the deploy directory. i.e. you should be able to unpack an hdk into the deploy directory, and then build, rebuild and test in a modular fashion using -Dbuild.module. I still have the build target work (described at the bottom of [1]) in my todo list - I think this will be more useful once (1) is finished. Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html As usual, I'm sure I'll find more work when I start looking more closely. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
