[classlib][test] fail statements omitted in many exception catching test cases
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related
with it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind without
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251\1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
.\concurrent\standard\src\test\java\AbstractExecutorServiceTest.java:215\235\253\306\311\340\341\353\389\403\418\436\454\473\488\521\541\562\578\595\610\628\646\665\680\697\730\750\771
.\concurrent\standard\src\test\java\AbstractQueuedSynchronizerTest.java:76\92\162\365\514\531\631\645\660\677\692\709\724\741\756\976\1007\1039\1236\1260
.\concurrent\standard\src\test\java\AbstractQueueTest.java:62\74\94\115\128\140\154\169\183
Re: [general] jre and hdk snapshots posted to general snapshot site
Some times ago we discussed (and agreed?) that the HDK should include tests (also as support.jar which already included) and issue 984 was filed to build test.jar. It will nice if test.jar will be added to the new version of HDK :) 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
Ok here is some details on threading library changes. Most of changes in TM affects two files thread_native_basic.c and thread_java_basic.c. Lets start with the first one. Main cause of all modification in that file comes from refactoring hythread_attach_to_group and hythread_detach functions. 1) hythread_attach_to_group a) new hythread_library_t parameter was added to the function signature. What for? For multi VM :-) When you attaches a thread to a thread library you need to specify to which particular library because each VM has its own. b) I've changed initialization/allocation of HyThread structure for attaching thread. Why? Bug in the current implementation. Input parameter (handle) is processed incorrectly. New instance of HyThread structure is created each time instead of using *handle one. This is expected behaviour according to specification of hythread_atach. So it is the bug. c) Setting TLS and changing thread status to alive and runnable is encapsulated in one place register_to_group. I will talk about it later. 2)hythread_detach a) originally there were two functions public hythread_detach and private destroy_thread. Each of them did its part of job when thread is not needed any more. I just merged them into one to make it easy to use and understand. Why? If you look closer to original hythread_detach it calls thread_destroy. So thread_destroy is a part of detaching. Fine. Lets jump to thread_start_proc. Look at shutdown sequence. It calls thread_destroy and sets TLS to NULL. Hmm this sequence does exactly the same as hythread_detach. Lets call hythread_detach instead. OK. Then what is the reason to have thread_destroy? When should we use thread_destroy instead of hythread_detach. I suspect never. If we do so we are asking for troubles. What I did? I concentrate all that stuff in one place. It is much linear I believe. 3) reset_thread, init_thread. There is a common problem with these two functions. They both add HyThread strucure to the specified thread group. It really bad. There are use cases when reset_thread called several times before a real thread is forked. In that case the same thread will be added to the group several times. Moreover reset_thread adds the thread to the same group each time what if I want to reuse HyThread structure but register it to another group. Ups doesn't work. So I moved group processing out of these functions. The last thing here is changing function name from init_thread to allocate_thread because it really allocates new HyThread structure. I don't insist on renaming but it seems new name reflects things better. 4) allocate_thread. I'm really confused by such names. There is init_thread that allocates new HyThread structure. And allocate_thread which adds allocated thread to the group. Sorry but I renamed it to allocate_thread and register_to_group correspondingly. In the current implementation code which deals with registering a thread to thread group is spread among three functions reset_thread, init_thread, allocate_thread... I put all that code in one place register_to_group and call when necessary. Seems to be easy That's all about hythread_native_basic.c. I need to leave my computer for a couple hours. I will come back with the second part Evgueni On 9/27/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Alexey Varlamov [26/Sep/06 05:11 AM] Evgueni, thank you, quite impressive work! Unfortunately patch is so huge it is hard to understand at once. I understand your concern (about reformatting)... I feel very-very uncomfortable when I study purely formatted code. It always hard to understand some one's code especially if it is hard to read. That was not my intention to fix indenting I just can't study such code and reformat it on the fly Sorry, I don't know how to switch my patch to the original formatting. And what really bothers, is that about half of it is just reformatting :( Can't we really go without white space changes and renaming of parameters\local vars??? Its definitely much less than the half of the patch. Kind request: could you please describe shortly what is done in TM - which essential changes enhancements? I think a lot of people are interested in answer to this question. Do you? Let me get a break and I will come up with details Right, it seems like invocation API patch does extensive changes to the TM design and interfaces. Hopefully you can provide us with a summary why it was done so. Sure! In the meantime, there are a few things I'd like to understand first (I didn't look through the whole patch yet though): (1) Why did you have to add JavaVM to jthread_create and jthread_attach functions? I couldn't see the use for JavaVM in the TM code, except putting it into TLS which can always be done outside of TM if one wishes to do so. Ideally, we
Re: [classlib][test] fail statements omitted in many exception catching test cases
Maybe we have to review the tests one by one. ;-)
On 9/27/06, Robert Hu [EMAIL PROTECTED] wrote:
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related with it. If a
line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind without any
victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251\1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
.\concurrent\standard\src\test\java\AbstractExecutorServiceTest.java:215\235\253\306\311\340\341\353\389\403\418\436\454\473\488\521\541\562\578\595\610\628\646\665\680\697\730\750\771
.\concurrent\standard\src\test\java\AbstractQueuedSynchronizerTest.java:76\92\162\365\514\531\631\645\660\677\692\709\724\741\756\976\1007\1039\1236\1260
.\concurrent\standard\src\test\java\AbstractQueueTest.java:62\74\94\115\128\140\154\169\183
Re: [classlib][test] fail statements omitted in many exception catching test cases
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~ /\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED] wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases about excep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the exception
-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of our Har
mony classlib. So I set some rules to find out all lines of code related with
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules in r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileIn
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind without
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pl
s. share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI=
nputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallba=
ckTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTe=
st.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionT=
est.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermission=
Test.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\25=
7\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java=
:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialT=
est.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.j=
ava:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\11=
41\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigPars=
Re: [classlib][math]three tests fail, anyone else see this?
Let me take a look -- I applied that patch.
Regards,
Tim
Stepan Mishura wrote:
Yes, is see failures. I guess that a cause may be math module
internalization.
Thanks,
Stepan.
On 9/27/06, Paulex Yang wrote:
Anyone else see these test errors of BigDecimalConstructorsTest?
testConstrDoubleNaNFailureImproper exception message
expected:...e... but was:...y...
testConstrDoublePosInfinityFailureImproper exception message
expected:...e... but was:...y...
testConstrDoubleNegInfinityFailureImproper exception message
expected:...e... but was:...y...
I believe it is caused by the patch of i18n message properties, it
returns Infinity or NaN, I've updated it at revision r450333, but is
it necessary to verify exception message so strictly like this?
code
try {
new BigDecimal(a);
fail(NumberFormatException has not been caught);
} catch (NumberFormatException e) {
assertEquals(Improper exception message, Infinite or NaN,
e.getMessage());
}
/code
--
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]
--
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]
Wonka, Mika, and Apache
Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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][math]three tests fail, anyone else see this?
On 9/27/06, Tim Ellison [EMAIL PROTECTED] wrote:
Let me take a look -- I applied that patch.
It seems that Paulex had fixed this issue. ;-)
Best regards,
Richard
Regards,
Tim
Stepan Mishura wrote:
Yes, is see failures. I guess that a cause may be math module
internalization.
Thanks,
Stepan.
On 9/27/06, Paulex Yang wrote:
Anyone else see these test errors of BigDecimalConstructorsTest?
testConstrDoubleNaNFailureImproper exception message
expected:...e... but was:...y...
testConstrDoublePosInfinityFailureImproper exception message
expected:...e... but was:...y...
testConstrDoubleNegInfinityFailureImproper exception message
expected:...e... but was:...y...
I believe it is caused by the patch of i18n message properties, it
returns Infinity or NaN, I've updated it at revision r450333, but is
it necessary to verify exception message so strictly like this?
code
try {
new BigDecimal(a);
fail(NumberFormatException has not been caught);
} catch (NumberFormatException e) {
assertEquals(Improper exception message, Infinite or NaN,
e.getMessage());
}
/code
--
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]
--
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]
--
Richard Liang
China 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] fail statements omitted in many exception catching test cases
Hi Robert,
Nice work! I've checked the entries for classes from the beans module.
It seems you found at least three bugs in tests for beans:
Bugs:
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:1388
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:449
Valid:
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304
needs more investigation
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92
.\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334
Thank you for this. I will file corresponding JIRA.
Regards,
2006/9/27, Robert Hu [EMAIL PROTECTED]:
Hi All,
In our unit test of classlib, there are huge number of test cases about
exception catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the
exception-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of our
Harmony classlib. So I set some rules to find out all lines of code related with it. If a
line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
style.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711(line
number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileInputStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOutputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind without any
victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs? Pls.
share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarFileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\DeflaterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\1099\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipFileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipInputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallbackTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTest.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionTest.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermissionTest.java:267\386
.\auth\src\test\java\common\javax\security\auth\SubjectTest.java:239\248\257\269\992\1109\1301\1314\1423\1851\2049\2061\2089\2101\2127\2139
.\auth\src\test\java\common\javax\security\auth\x500\X500PrincipalTest.java:2404
.\auth\src\test\java\common\javax\security\auth\x500\X500PrivateCredentialTest.java:169\179\189
.\auth\src\test\java\common\org\apache\harmony\auth\internal\SecurityTest.java:807\855\950\971\987\995\1003\1011\1065\1089\1090\1101\1116\1125\1133\1141\1142\1151\1152\1161\1162
.\auth\src\test\java\common\org\apache\harmony\auth\login\DefaultConfigParserTest.java:79\182
.\awt\src\test\api\java\common\java\awt\color\ICC_ProfileRTest.java:37
.\awt\src\test\api\java\common\java\awt\ComponentTest.java:751
.\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:652\658\664\670\676\685\698\704\711
.\awt\src\test\api\java\windows\org\apache\harmony\awt\tests\java\awt\WinFontTest.java:427
Re: [drlvm] [launcher] Executable hangs
Armand Navabi wrote: What is the kernel version BTW? There could be some issues with 2.4.x, currently everybody works with 2.6.x The kernel version is 2.6.17.8. concerning hythread_exit .. Did you resolve it already? I see the symbol _undefined_ too (and no definition of the symbol in hythread.so or any other lib, although sources are fine, probably some bug in the build system), but dynamic linker does not complain on my machine. No, I did not resolve this problem. When I try to run ./java by itself I see the following: ../java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. From what I've seen, hythread_exit() is not used by launcher in a normal code path, and this message is only shown when running java without parameters (or if the VM loading failed for some reason). - 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-1582 - invocation API for DRLVM
On 9/27/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 26 September 2006 17:25 Geir Magnusson Jr. wrote: Wanted to start a new thread with better subject line. I want to take part in this thread too. 1. As Tim has mentioned in a separate thread the multiVM support requires that we don't use global and static variables in native code. One global variable used often in drlvm across all of the code is Global_Env::loader_env. I didn't find it in the patch code so I want to ask you, did you move this pointer into TLS? Not exactly. You are right I tried to write the code which supports multi VM. But that was not my main goal at this moment. So what I did in that direction is 1) I added JNIEnv * into VM_thread structure. So you can always get a Global_Env having JNIEnv. Probably it makes sense to use VM local storage to keep Global_Env as well. I consider it as another tasknot InvocationAPI 2) Localized thread library instance for each VM. 3) Fixed those places where Global_Env can be extracted from JNI_Env *. see jni_get_vm_env function. 2. Can we get avoid all of the CR-LF EOLs introduced in this patch? I will do my best in the future. I promise :-) Evgueni -- 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]
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: Thanks. Yes, this is supposed to be review by JIT person. On the other hand, if JIT person has better solution, GCv5 would like to use. Anyway we hope write barrier is to be functioning in the DRLVM soon. As a JIT-oriented guy, I looked through the patch. Looks good. The write barrier does NOT push an M2N frame before invoking gc_heap_slot_write_ref(), but it's OK since there will be no stack unwinding from here. I am curious about the switch VM_Global_State::loader_env-use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? On 9/27/06, Weldon Washburn [EMAIL PROTECTED] wrote: It would probably be best if a JIT person committed this patch. Maybe Stephan Mishura? If its not committed soon, bug me and I will do it. On 9/26/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write barrier implementation for JET that GCv5 is going to use (it doesn't impact anything else). It would be great if some commiter can help to review and commit it. Thanks. -xiaofeng http://issues.apache.org/jira/browse/HARMONY-1580?page=all The patch is against revision revision 442796. Repeat the desciption of the patch: Attached patch is an implementation of write barrier for JET compiler of DRLVM. The patch lets JET to call gc_requires_barriers() of GC to determine if it needs to insert the write barrier code into the jitted code, so it doesn't impact current DRLVM/GC at all. It calls gc_heap_slot_write_ref( ) of GC module, which takes three parameters. The signature is void gc_heap_slot_write_ref (Managed_Object_Handle p_obj_holding_ref,Managed_Object_Handle *p_slot, Managed_Object_Handle p_target). The patch is based on revision 442796. We hope it can be committed to Harmony soon because GCv5 will be depending on it. We don't use existing getaddress__gc_write_barrier_fastcall () in DRLVM because it only remembers object rather than the slot, and the name is not descriptive. But we may use it later. Thanks. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn 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] -- 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] [launcher] Executable hangs
On the 0x1F1 day of Apache Harmony Salikh Zakirov wrote: Armand Navabi wrote: What is the kernel version BTW? There could be some issues with 2.4.x, currently everybody works with 2.6.x The kernel version is 2.6.17.8. concerning hythread_exit .. Did you resolve it already? I see the symbol _undefined_ too (and no definition of the symbol in hythread.so or any other lib, although sources are fine, probably some bug in the build system), but dynamic linker does not complain on my machine. No, I did not resolve this problem. When I try to run ./java by itself I see the following: ../java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. hm, looks stange to me. I see a def of hythread_exit() in hythread.c:1530. Why it is not in libhythr.so is a mystery ;) From what I've seen, hythread_exit() is not used by launcher in a normal code path, and this message is only shown when running java without parameters (or if the VM loading failed for some reason). -- 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] [launcher] Executable hangs
Salikh Zakirov wrote: Armand Navabi wrote: ../java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. Just for the record, the fix for missing hythread_exit() is available in HARMONY-1590. - 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-1582 - invocation API for DRLVM
Here is the second part which provides details on thread_java_basic.c. 1) jthread_create_with_function a) JavaVM * java_vm argument instead of JNI_Env * env. First of all when jthread_create_with_function is called there is no jni environment created for new thread yet. It will be created when vm_jthread_attach is called. vm_jthread_attach wants to know to which VM current thread should be attached. That's why I pass java VM instead of JNI environment. As I sad once we can think of modifying current scheme and call vm_jthread_attach before jthread_create/jthread_attach. In that case it is reasonable to pass JNI_Env. b) removed support for irregular use. I think it is not very good to have that code for couple of reasons. First (not very important) it is useless actions in any real scenario. At least everything works just fine without it. Second it can hide a real problem. According to current design there should be no such cases when jthread object is not associated with hythread. It can be important to catch if something goes wrong as early as we could. c) removed temporary pool creation. Actually this pool has the same life time as global APR pool. So it is a memory leak. Moreover I just don't see any reason to create it. Lets use existing one with proper life time. d) daemon notion was moved to hythread layer. That's really discussable. See one of my previous mail. 2)jthread_attach a) signature has changed significantly. Hmm, that was required to implement InvocationAPI according to spec :-) Ask particular questions please if you have them. 3)jthread_detach same story as 2) 4) wrapper_proc: Seems like a lot of changes but not so many important. Only two changes are really significant: a) moved processing of non-daemon threads to hythread layer. Discussed earlier. b) added initialization of jvmti_thread-jenv field. Actually this is the only place when it is first available... Ups... it seems I missed jvmti_send_thread_start_end_event(1) in one of my merges need to be fixed. Thanks Evgueni On 9/27/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 26 September 2006 17:25 Geir Magnusson Jr. wrote: Wanted to start a new thread with better subject line. I want to take part in this thread too. 1. As Tim has mentioned in a separate thread the multiVM support requires that we don't use global and static variables in native code. One global variable used often in drlvm across all of the code is Global_Env::loader_env. I didn't find it in the patch code so I want to ask you, did you move this pointer into TLS? Not exactly. You are right I tried to write the code which supports multi VM. But that was not my main goal at this moment. So what I did in that direction is 1) I added JNIEnv * into VM_thread structure. So you can always get a Global_Env having JNIEnv. Probably it makes sense to use VM local storage to keep Global_Env as well. I consider it as another tasknot InvocationAPI 2) Localized thread library instance for each VM. 3) Fixed those places where Global_Env can be extracted from JNI_Env *. see jni_get_vm_env function. 2. Can we get avoid all of the CR-LF EOLs introduced in this patch? I will do my best in the future. I promise :-) Evgueni -- 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]
Re: [jira] Is it comfortable for committers when source and test patches are packed in the single diff file?
OK, thanks a lot. P.S. I have found your discussion about separate patches. 2006/9/27, Nathan Beyer [EMAIL PROTECTED]: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Geir Magnusson Jr. wrote: On Sep 26, 2006, at 10:23 AM, Denis Kishenko wrote: Geir, thanks for answer. As I understand committers don't run tests from issue's descriptions? Sometimes. But if a test can be provided, it makes things a lot easier on the committers, and improves chances of getting in. I agree -- and two patch files is just fine. Regards, Tim I'll add another vote to two patch files. I do exactly what Geir said; apply the test patch, run the tests to see the failure, then apply the source patch to see how it fixes the issue. -Nathan 2006/9/26, Geir Magnusson Jr. [EMAIL PROTECTED]: I really, really like two patches as we discussed on a different thread. That way, I can apply the test patch, show the bug, apply the source patch, show it's gone (and then screw up and not commit all the code in the patch ;) Tim was neutral, but didn't care, so there's no opposition to asking for two. geir On Sep 26, 2006, at 9:29 AM, Denis Kishenko wrote: Sometime I make two different diff files (source and test patches), sometime I make the single one. Does it make sense for committers? - 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] --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] - 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] - 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: [drlvm] [launcher] Executable hangs
Egor Pasko wrote: hm, looks stange to me. I see a def of hythread_exit() in hythread.c:1530. Why it is not in libhythr.so is a mystery ;) No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so, but DRLVM insists on using its own, different, libhythr.so. - 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] [launcher] Executable hangs
On the 0x1F0 day of Apache Harmony Armand Navabi wrote: What is the kernel version BTW? There could be some issues with 2.4.x, currently everybody works with 2.6.x The kernel version is 2.6.17.8. concerning hythread_exit .. Did you resolve it already? I see the symbol _undefined_ too (and no definition of the symbol in hythread.so or any other lib, although sources are fine, probably some bug in the build system), but dynamic linker does not complain on my machine. No, I did not resolve this problem. When I try to run ./java by itself I see the following: ./java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt.so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference And then it hangs. I did find that this would not happen (i.e. ./java would run just fine) if I overwrite libhythr.so with the libhythr.so from the classlib's /deploy/jdk/jre/bin directory. Is that a safe way to resolve this problem? hm, gdb .. did you 'export' LD_LIBRARY_PATH? (sorry for the dummy question:) No need apologize. I'm sure in the end it will be a dummy mistake that I'm making. But yes, I did export the LD_LIBRARY_PATH. I had it first set to the deploy/jre/bin directory. I also tried to set it to put deploy/jre/bin/default also in the path. Let me be clear when I say I am unable to debug with gdb. First the problem I am having is when I try to set a breakpoint I always see this: (gdb) b jni.cpp:478 No source file named jni.cpp. Make breakpoint pending on future shared library load? (y or [n]) y I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put somewhere in ~/.gdbinit, two scripts are better: first for initial run, the second script does the same but reusing old breakpoint numbers: dis en 1 r dis en 2 c dis I should put that into the FAQ, obviously. And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. this one is probably a separate issue (not connected with future shared library load). Try my above suggestion, please. GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11007)] [New Thread 32769 (LWP 11010)] [New Thread 16386 (LWP 11011)] Cannot find thread 32769: invalid thread handle (gdb) q The program is running. Exit anyway? (y or n) y [1]+ Stopped gdb ./java Thanks, Armand On the 0x1F0 day of Apache Harmony Armand Navabi wrote: When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to find when it hangs. I see the following: Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Also, when I run ./java -Xtrace:em, I get the following (and it hangs): ... EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Again, it seems to always hang after FindClass is called for java/lang/Thread. I have tried setting LD_LIBRARY_PATH as suggested earlier. I also have JAVA_HOME set (and I have tried it with it unset). Everything seems to have the same behavior. [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/
Re: [drlvm] [launcher] Executable hangs
On the 0x1F1 day of Apache Harmony Salikh Zakirov wrote: Egor Pasko wrote: hm, looks stange to me. I see a def of hythread_exit() in hythread.c:1530. Why it is not in libhythr.so is a mystery ;) No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so, but DRLVM insists on using its own, different, libhythr.so. Salikh, thank you for clarification. -- 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: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
So... If there is now EXPORTS section advocates I will prepare a patch to remove them from the def files for Windows. SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: Guys, investigation shown that if we remove EXPORTS section from the def file then the result dll has correct names. Is there any objections on removing EXPORTS sections from the def files on Windows? SY, Alexey 2006/9/20, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [build?] Some of the Harmony jni libraries has wrong function names inside -- Key: HARMONY-1505 URL: http://issues.apache.org/jira/browse/HARMONY-1505 Project: Harmony Issue Type: Bug Components: Classlib Environment: Windows Reporter: Alexey Petrenko Some of the Harmony jni libraries, for example hyluni.dll, has function names which are not prefixed by underscore ( _ ). JNI spec says that all the JNI methods on Windows should be declared as __stdcall. [1] And MS C documentation says that __stdcall function names should be prefixed by underscore. [2] [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexey A. Petrenko Intel Middleware Products Division -- 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 12:52 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 10:47 PM, Vladimir Ivanov wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: ... Right, but the system can easily automate doing the three steps in phases. The build-test infrastructure does that already. Well get timing info too... Yes, but some people want to receive one notification for one module (like 'classlib OK' that means ws was built and all tests passed). In the current model this feature is not accessible. Why not? If someone wanted that, I'd design it so no mail is send on success of fetch and build, but only on tests. In this case he will miss the 'build-broken' event. We seem to be having a bit of a communication issue. No, he wouldn't miss it, because the system would send mail in that case. The system would send mail in case of failure for every case, and only success for the tests, as you seemed to be asking. Actually, my configuration wouldn't send mail for anything except transition - first failure, and then first recovery... ... The external tool may implement some build sequences but seems it should be defined be build itself. It is defined by build, but people are given the freedom of individual piece-parts for good reason. Nobody takes away the freedom. My suggestion was to add flexibility: if somebody wants build and test Harmony by one command he can easily do it (not now). If other peoples want to do it step-by-step it is OK. It is their choice. But build should provide both capabilities (at least, while it costs nothing - 1 line of code). Agreed - but who wants that now? IOW, what are you doing that requires this? Sometimes I checkout ws as clean and for me it will be convenient to fetch-depend, build and test it at one moment. Of cause, it is not too often :) By the way, the build-test infrastructure may be updated to support both modes by switch: do all commands step-by-step or run one command. I guess I still don't understand why, since I don't see to the user what the difference is if the system does three actions, or just one. For CC, the difference is three or one notification if user does not want to miss some events. But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. geir thanks, Vladimir geir thanks, Vladimir geir thanks, Vladimir Issue http://issues.apache.org/jira/browse/HARMONY-1565 with trivial update was created. So do we really need this? geir thanks, Vladimir geir Thanks, Vladimir -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 3:31 PM Subject: [jira] Updated: (HARMONY-995) [testing] add support of proxy settings for get-task To: [EMAIL PROTECTED] [ http://issues.apache.org/jira/browse/HARMONY-995? page=all ] Vladimir Ivanov updated HARMONY-995: Attachment: build.patch add notification, timeouts etc [testing] add support of proxy settings for get-task Key: HARMONY-995 URL: http://issues.apache.org/jira/ browse/ HARMONY-995 Project: Harmony Issue Type: Bug Components: build - test - ci Reporter: Vladimir Ivanov Priority: Minor Attachments: build.patch, build.xml.patch, build.xml.patch 1) add external property file with proxy settings to use it int the build.xml for get task (when needed). 2) add '/c' symbol to run CC on win 3) seems, that readme.txt file should be updated to point as define proxy for svn and get certificate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http:// www.atlassian.com/ software/jira - 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,
Re: [drlvm] [launcher] Executable hangs
FWIW, Thanks for sticking with us on this. I'm sure we'll find it. geir On Sep 27, 2006, at 1:35 AM, Armand Navabi wrote: Gregory Shimansky wrote: I think not. DRLVM needs its own threading library. The reason is discussed in a separate thread thread library - let there be one. I am not sure I understand all the reasoning for separate libhythr.so implementation, but I know the drlvm version should be in bin/ and bin/default/ directories. Ok, I read that thread. Is there an easy temporary fix to this? What is the reason to set breakpoint in jni.cpp:478? It is a condition that if JNI FindClass is called in exception state it shouldn't do anything, just return NULL. I'm sorry, my line 478 is different than yours, because I have other prints and things in there. I was not putting the breakpoint on the line that checks if it is called in exception state. Basically, I just put a print inside of that procedure because I traced the hanging to that method (or so I thought). My point was that I am unable to breakpoints anywhere in jni.cpp. Below you have explained what problem that is related to. And as far as tracing, you have suggested a much more efficient way to trace where it is going in the code. Thanks. Make breakpoint pending on future shared library load? (y or [n]) y And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. The solution for this was found and discussed in thread APR fails to load a JIT library when using a fully qualified path. The launcher execs itself with a new environment setting for LD_LIBRARY_PATH and gdb cannot work around this. I reread those threads and it seems some changes were suggested. Have these changes been made. I couldn't see (or perhaps couldn't figure out) any way to quickly fix this from the discussions. It seemed as though people were suggesting moving and merging libraries. If it has been fixed, I should have it because I have recently updated. I have a proposal for you. Run java -Xthread -Xtrace Hello for hello world application. The -Xtrace option will produce a lot of output but it will enable all debugging tracing in drlvm and when it hangs for you it will be a very close location to the reason of the problem. If there is no output with -Xtrace, then it probably means launcher problems. Please update the sources, some launcher problems were resolved just recently I updated all the classlib and drlvm code earlier today. Just to make sure we are talking about the same thing here, I have compiled helloworld.java separately with Sun's compiler and then I made sure it ran (it runs both with Sun's java and the classlib with IBM's VM), and then I moved it to the drlvm's bin directory. There is no particular Hello application you are talking about correct? The application I am running was a java program I wrote myself and compiled. And then I tried to run my hello world application as you said. Like you said it produced a lot of output and towards the end when it hanged, this is the last output it produced: [0x4000] : Looking for native: java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I [0x4000] : trying: Java_java_lang_VMThreadManager_start [0x4000] : Compiled method java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I, entry 0xb68a4000 [0x4000] : GetObjectClass called [0x4000] : GetObjectClass: class = java/lang/FinalizerThread [0x4000] : GetFieldID called [0x4000] : GetFieldID java/lang/FinalizerThread.vm_thread J = 0x8286894 [0x4000] : GetLongField called, id = 0x8286894 [0x4000] : IsInstanceOf called [0x4000] : GetObjectClass called [0x4000] : GetObjectClass: class = java/lang/FinalizerThread [0x8003] : gc_thread_init 0x807d720 [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 0x8633a18 [0x8003] : 0x8633a18 0x807d660 I java/lang/Thread [0x8003] : Loader U (0x8633a18) loading class: java/lang/Thread... [0x8003] : enter method java/lang/ClassLoader loadClass (Ljava/lang/String;)Ljava/lang/Class; At this point, it hangs, and I am forced to Cntrl^c to kill the process. 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] - Terms of use :
Re: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
On 27 September 2006 at 15:18, Alexey Petrenko [EMAIL PROTECTED] wrote: So... If there is now EXPORTS section advocates I will prepare a patch to remove them from the def files for Windows. If removing them means we are exporting all symbols, then I'd rather keep explicit exports of the symbols we intend to be public. Is there no way to fix it and keep the explicit list of public symbols? -Mark. SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: Guys, investigation shown that if we remove EXPORTS section from the def file then the result dll has correct names. Is there any objections on removing EXPORTS sections from the def files on Windows? SY, Alexey 2006/9/20, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [build?] Some of the Harmony jni libraries has wrong function names insid e - - Key: HARMONY-1505 URL: http://issues.apache.org/jira/browse/HARMONY-1505 Project: Harmony Issue Type: Bug Components: Classlib Environment: Windows Reporter: Alexey Petrenko Some of the Harmony jni libraries, for example hyluni.dll, has function n ames which are not prefixed by underscore ( _ ). JNI spec says that all the JNI methods on Windows should be declared as _ _stdcall. [1] And MS C documentation says that __stdcall function names shoul d be prefixed by underscore. [2] [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexey A. Petrenko Intel Middleware Products Division -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
MS VC documentation recommends to use __declspec(dllexport) option instead of EXPORTS section. In our case it is JNIEXPORT. And all of the JNI functions are marked as JNIEXPORT. 2006/9/27, Mark Hindess [EMAIL PROTECTED]: On 27 September 2006 at 15:18, Alexey Petrenko [EMAIL PROTECTED] wrote: So... If there is now EXPORTS section advocates I will prepare a patch to remove them from the def files for Windows. If removing them means we are exporting all symbols, then I'd rather keep explicit exports of the symbols we intend to be public. Is there no way to fix it and keep the explicit list of public symbols? -Mark. SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: Guys, investigation shown that if we remove EXPORTS section from the def file then the result dll has correct names. Is there any objections on removing EXPORTS sections from the def files on Windows? SY, Alexey 2006/9/20, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [build?] Some of the Harmony jni libraries has wrong function names insid e - - Key: HARMONY-1505 URL: http://issues.apache.org/jira/browse/HARMONY-1505 Project: Harmony Issue Type: Bug Components: Classlib Environment: Windows Reporter: Alexey Petrenko Some of the Harmony jni libraries, for example hyluni.dll, has function n ames which are not prefixed by underscore ( _ ). JNI spec says that all the JNI methods on Windows should be declared as _ _stdcall. [1] And MS C documentation says that __stdcall function names shoul d be prefixed by underscore. [2] [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexey A. Petrenko Intel Middleware Products Division -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [drlvm] [launcher] Executable hangs
applied. thx On Sep 27, 2006, at 6:36 AM, Salikh Zakirov wrote: Salikh Zakirov wrote: Armand Navabi wrote: ../java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/ libhyprt..so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. Just for the record, the fix for missing hythread_exit() is available in HARMONY-1590. - 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: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 3:10 AM, Vladimir Ivanov wrote: Some times ago we discussed (and agreed?) that the HDK should include tests (also as support.jar which already included) and issue 984 was filed to build test.jar. It will nice if test.jar will be added to the new version of HDK :) I think it's good to have the tests there too. However, is there any downside to this? might we cause trouble for people using the HDK for development (rather than the build test infra?) If some doubts exist we can vote about it. I can not see any downside to have one more jar in the HDK. 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: [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]
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 7:58 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 3:10 AM, Vladimir Ivanov wrote: Some times ago we discussed (and agreed?) that the HDK should include tests (also as support.jar which already included) and issue 984 was filed to build test.jar. It will nice if test.jar will be added to the new version of HDK :) I think it's good to have the tests there too. However, is there any downside to this? might we cause trouble for people using the HDK for development (rather than the build test infra?) If some doubts exist we can vote about it. LOL. No reason to vote - it's a technical issue with a single true'false answer - would having a single jar of tests screw up a developer using the HDK as originally intended, namely as a means to allow them to just checking one classlib module, and use HDK to supply the rest of the required headers, libraries and classes needed for building and testing. if the answer is yes, then we need to figure out how to deal with it. If no, then there's no problem and we go forward. The question here isn't do we want the test.jar - because I think we all do. The question is how do we do this conveniently and safely? I can not see any downside to have one more jar in the HDK. The problem could arise if that test.jar was used before the classes in the checked-out module, masking any changes or such that the developer was making. 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: [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]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: We seem to be having a bit of a communication issue. No, he wouldn't miss it, because the system would send mail in that case. The system would send mail in case of failure for every case, and only success for the tests, as you seemed to be asking. Actually, my configuration wouldn't send mail for anything except transition - first failure, and then first recovery... I know. I just do small update for yor system :) But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. Agree. But instead of one line of code in the build we have 20+ in the tool (and 3 in my bat-file to do full testing cycle for classlib). Of cause, tool can do it (and do now) but we can do some things more easy. thanks, Vladimir geir
Re: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If some doubts exist we can vote about it. LOL. No reason to vote - it's a technical issue with a single true'false answer - would having a single jar of tests screw up a developer using the HDK as originally intended, namely as a means to allow them to just checking one classlib module, and use HDK to supply the rest of the required headers, libraries and classes needed for building and testing. if the answer is yes, then we need to figure out how to deal with it. If no, then there's no problem and we go forward. The question here isn't do we want the test.jar - because I think we all do. The question is how do we do this conveniently and safely? I can not see any downside to have one more jar in the HDK. The problem could arise if that test.jar was used before the classes in the checked-out module, masking any changes or such that the developer was making. So, conclusion is: - while we does not provide scripts to run tests from this test.jar we have no problems here;\ - when we will prepare scripts we should add tests from modules before this test.jar (or prepare 2 separated scripts). Do I miss something? 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: [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]
[drlvm] HARMONY-1559 patch causes SIGABRT in VM code
Hi all, after HARMONY-1559 patch has been committed, kernel unit test RuntimeTest started to fail on linux in the interpreter mode. It loops with the message [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:211: StackIterator* si_create_from_native(): Assertion `!interpreter_enabled()' failed. and fails on timeout. I rolled back the changes and test passed. -- Thanks, Elena
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 8:21 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If some doubts exist we can vote about it. LOL. No reason to vote - it's a technical issue with a single true'false answer - would having a single jar of tests screw up a developer using the HDK as originally intended, namely as a means to allow them to just checking one classlib module, and use HDK to supply the rest of the required headers, libraries and classes needed for building and testing. if the answer is yes, then we need to figure out how to deal with it. If no, then there's no problem and we go forward. The question here isn't do we want the test.jar - because I think we all do. The question is how do we do this conveniently and safely? I can not see any downside to have one more jar in the HDK. The problem could arise if that test.jar was used before the classes in the checked-out module, masking any changes or such that the developer was making. So, conclusion is: - while we does not provide scripts to run tests from this test.jar we have no problems here;\ - when we will prepare scripts we should add tests from modules before this test.jar (or prepare 2 separated scripts). Do I miss something? One of us is. 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. 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. 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]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
sob :) Is there an easy fix, or do we rollback? geir On Sep 27, 2006, at 8:32 AM, Elena Semukhina wrote: Hi all, after HARMONY-1559 patch has been committed, kernel unit test RuntimeTest started to fail on linux in the interpreter mode. It loops with the message [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ ia32/pim/stack_iterator_ia32.cpp:211: StackIterator* si_create_from_native(): Assertion `! interpreter_enabled()' failed. and fails on timeout. I rolled back the changes and test passed. -- 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: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: Thanks :) On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Here's a badge for you to cut out and wear g +-+ | Harmony | | Champion! | +-+ Keep up the good work! Regards, Tim Vladimir Ivanov wrote: It is my 200 issue in Harmony. Seems, I'm the champion :) -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 7:50 PM Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run To: [EMAIL PROTECTED] [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run --- Key: HARMONY-1569 URL: http://issues.apache.org/jira/browse/HARMONY-1569 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Vladimir Ivanov Now, the system JAVA_HOME variable is used. The value should point to tested runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] -- 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 8:14 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. Agree. But instead of one line of code in the build we have 20+ in the tool (and 3 in my bat-file to do full testing cycle for classlib). Of cause, tool can do it (and do now) but we can do some things more easy. Can I ask what you are trying to do? The build-test thingy wont' get simpler because of this patch, because we want the build-test tool to record it's actions in fine detail, and the only way to do that is to do the actions individually. Therefore, calling some do-everything target is a non-starter as lots of important information will be lost, with the only gain I can see is saving 19 lines of code that we'd write once and everyone would use. it just hides information for no gain. Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it 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: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: Thanks :) On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Here's a badge for you to cut out and wear g +-+ | Harmony | | Champion! | +-+ Keep up the good work! Regards, Tim Vladimir Ivanov wrote: It is my 200 issue in Harmony. Seems, I'm the champion :) -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 7:50 PM Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run To: [EMAIL PROTECTED] [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run - -- Key: HARMONY-1569 URL: http://issues.apache.org/jira/browse/ HARMONY-1569 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Vladimir Ivanov Now, the system JAVA_HOME variable is used. The value should point to tested runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- 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] - 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 just wondered what changed after yesterday, rolled back HARMONY-1559 patch and so discovered cause-effect relation. I can say nothing about the fix, we should ask the patch submitter :( On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: sob :) Is there an easy fix, or do we rollback? geir On Sep 27, 2006, at 8:32 AM, Elena Semukhina wrote: Hi all, after HARMONY-1559 patch has been committed, kernel unit test RuntimeTest started to fail on linux in the interpreter mode. It loops with the message [junit] SIGABRT in VM code. [junit] java: /nfs/ins/proj/drl/coreapi/esemukhi/git/drlvm/trunk/vm/port/src/lil/ ia32/pim/stack_iterator_ia32.cpp:211: StackIterator* si_create_from_native(): Assertion `! interpreter_enabled()' failed. and fails on timeout. I rolled back the changes and test passed. -- Thanks, Elena -- Thanks, Elena
Re: [doc] new Getting Started guides
Hi Geir, Those new documents look really good. I just found a few spelling mistakes on the first one (http://incubator.apache.org/harmony/quickhelp_users.html). In the first paragraph no development tools our need to should probably be no development tools or need to. In the fourth paragraph run well on the paltforms offered should be run well on the platforms offered and in the fifth paragraph I think unpack inÄto a jre directory should be unpack into a jre directory. I hope you don't think I'm being picky - I just think it's better for the project's image if we have correct spelling and grammar etc on the website. Thanks, Sian On 22/09/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As discussed earlier today, there are now two new Getting Started guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sian January IBM Java Technology Centre, UK
Re: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
do you wear such one =) 2006/9/27, Geir Magnusson Jr. [EMAIL PROTECTED]: you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: Thanks :) On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Here's a badge for you to cut out and wear g +-+ | Harmony | | Champion! | +-+ Keep up the good work! Regards, Tim Vladimir Ivanov wrote: It is my 200 issue in Harmony. Seems, I'm the champion :) -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 7:50 PM Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run To: [EMAIL PROTECTED] [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run - -- Key: HARMONY-1569 URL: http://issues.apache.org/jira/browse/ HARMONY-1569 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Vladimir Ivanov Now, the system JAVA_HOME variable is used. The value should point to tested runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- 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] - 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 8:14 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: But you can send just one email with a summary of everything that happened during that run. The fact that the system did : call fetch-depends call build clean call build call test should have no bearing on how many emails it sends. Agree. But instead of one line of code in the build we have 20+ in the tool (and 3 in my bat-file to do full testing cycle for classlib). Of cause, tool can do it (and do now) but we can do some things more easy. Can I ask what you are trying to do? The build-test thingy wont' get simpler because of this patch, because we want the build-test tool to record it's actions in fine detail, and the only way to do that is to do the actions individually. Therefore, calling some do-everything target is a non-starter as lots of important information will be lost, with the only gain I can see is saving 19 lines of code that we'd write once and everyone would use. it just hides information for no gain. Sorry, I can not see any place where we hide information. Build logs will be available with the same details. Strictly speaking, nothing will change (except script simplification) - just some legal build sequence will be moved from external tool to the build system. thanks, Vladimir Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it 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: Wonka, Mika, and Apache
There certainly is interest in Apache Harmony, as this is very much aligned to what we've already been doing for the past year and a few months. geir On Sep 27, 2006, at 5:09 AM, Chris Gray wrote: Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/ Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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: [general] jre and hdk snapshots posted to general snapshot site
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]
Re: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
I have a tattoo. geir On Sep 27, 2006, at 8:52 AM, Denis Kishenko wrote: do you wear such one =) 2006/9/27, Geir Magnusson Jr. [EMAIL PROTECTED]: you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: Thanks :) On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Here's a badge for you to cut out and wear g +-+ | Harmony | | Champion! | +-+ Keep up the good work! Regards, Tim Vladimir Ivanov wrote: It is my 200 issue in Harmony. Seems, I'm the champion :) -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 7:50 PM Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run To: [EMAIL PROTECTED] [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run - -- Key: HARMONY-1569 URL: http://issues.apache.org/jira/browse/ HARMONY-1569 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Vladimir Ivanov Now, the system JAVA_HOME variable is used. The value should point to tested runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- Denis M. Kishenko Intel Middleware Products Division - 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 9:11 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Can I ask what you are trying to do? The build-test thingy wont' get simpler because of this patch, because we want the build-test tool to record it's actions in fine detail, and the only way to do that is to do the actions individually. Therefore, calling some do-everything target is a non-starter as lots of important information will be lost, with the only gain I can see is saving 19 lines of code that we'd write once and everyone would use. it just hides information for no gain. Sorry, I can not see any place where we hide information. Build logs will be available with the same details. Strictly speaking, nothing will change (except script simplification) - just some legal build sequence will be moved from external tool to the build system. How will you be able to grab that information from the logs, so I can see histories and such? I'm not going to go manually scanning logs. I want a web page that shows me the history. This is what the CI system does right now. Why would we want to reverse that? I want to be able to graph the times to look for aberrations I guess you can write log-scanning code, but that seems to be longer than the 19 extra lines that would be in the script for cruise control... geir thanks, Vladimir Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it geir - 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]
Re: [jira] Created: (HARMONY-1505) [build?] Some of the Harmony jni libraries has wrong function names inside
Investigation shown another problem... Number of JNI methods in archive and luni modules does not marked with JNIEXPORT as it required by the spec. This issue should be also fixed. I'll split the original (1505) issue on two subtasks. To make patches smaller. SY, Alexey 2006/9/27, Alexey Petrenko [EMAIL PROTECTED]: MS VC documentation recommends to use __declspec(dllexport) option instead of EXPORTS section. In our case it is JNIEXPORT. And all of the JNI functions are marked as JNIEXPORT. 2006/9/27, Mark Hindess [EMAIL PROTECTED]: On 27 September 2006 at 15:18, Alexey Petrenko [EMAIL PROTECTED] wrote: So... If there is now EXPORTS section advocates I will prepare a patch to remove them from the def files for Windows. If removing them means we are exporting all symbols, then I'd rather keep explicit exports of the symbols we intend to be public. Is there no way to fix it and keep the explicit list of public symbols? -Mark. SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: Guys, investigation shown that if we remove EXPORTS section from the def file then the result dll has correct names. Is there any objections on removing EXPORTS sections from the def files on Windows? SY, Alexey 2006/9/20, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [build?] Some of the Harmony jni libraries has wrong function names insid e - - Key: HARMONY-1505 URL: http://issues.apache.org/jira/browse/HARMONY-1505 Project: Harmony Issue Type: Bug Components: Classlib Environment: Windows Reporter: Alexey Petrenko Some of the Harmony jni libraries, for example hyluni.dll, has function n ames which are not prefixed by underscore ( _ ). JNI spec says that all the JNI methods on Windows should be declared as _ _stdcall. [1] And MS C documentation says that __stdcall function names shoul d be prefixed by underscore. [2] [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp615 [2] http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: h ttp://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexey A. Petrenko Intel Middleware Products Division -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division -- 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: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
I should guess 2006/9/27, Geir Magnusson Jr. [EMAIL PROTECTED]: I have a tattoo. geir On Sep 27, 2006, at 8:52 AM, Denis Kishenko wrote: do you wear such one =) 2006/9/27, Geir Magnusson Jr. [EMAIL PROTECTED]: you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: Thanks :) On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Here's a badge for you to cut out and wear g +-+ | Harmony | | Champion! | +-+ Keep up the good work! Regards, Tim Vladimir Ivanov wrote: It is my 200 issue in Harmony. Seems, I'm the champion :) -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 7:50 PM Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run To: [EMAIL PROTECTED] [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run - -- Key: HARMONY-1569 URL: http://issues.apache.org/jira/browse/ HARMONY-1569 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Vladimir Ivanov Now, the system JAVA_HOME variable is used. The value should point to tested runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- Denis M. Kishenko Intel Middleware Products Division - 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] -- 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] - 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: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
I put the initial version of MSVC2003 build into JIRA [ http://issues.apache.org/jira/browse/HARMONY-1607 ] This version contains only Jitrino/EM/Encoder projects and I'm going to add more modules soon. If anyone is interested to discuss the details or have something to add I propose to use this thread and the same JIRA. On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 1:29 PM, Tim Ellison wrote: the various cruft we have around for Eclipse 'Cruft' doesn't seem to appear in my copy of the Oxford English Dictionary. I assume it means 'high fidelity development environment artifacts' right? :o) Exactly. Cruft :) I'm ok with putting in some VS metadata too. Regards, Tim Geir Magnusson Jr. wrote: Just so we're all on the same page... This is understood to be like the various cruft we have around for Eclipse - nice to have for developers but not a supported way to build the project? geir On Sep 25, 2006, at 2:14 PM, Gregory Shimansky wrote: On Monday 25 September 2006 19:24 Mikhail Fursov wrote: I spent a couple of hours today investigating this bug. The result is: this is not a bug, this is the problem of the MSVC project file I use to build and to debug JIT. So it was my error. BTW: if anyone is interested to use MSVC project files to build JIT or other components of DRLVM I can put them into JIRA and support these files in the nearest future. I think this would be very useful for development on windows. I don't use VS.NET for anything but debugging but then project is useful to find some symbol's definition/declaration and helps the debugger to understand the symbol info. +1. --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: 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
[classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff src.length || dstOff dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
2006/9/27, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[], int,
int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number
of points to transform is zero. Harmony doesn't throw any exception. Spec
doesn't say about any exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation
doesn't use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
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: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
On 9/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: If anyone is interested to discuss the details or have something to add I propose to use this thread and the same JIRA. I was wrong when proposed to use this email thread for the discussion. The subject is not suitable at all. I will start new thread. -- Mikhail Fursov
Re: [general] jre and hdk snapshots posted to general snapshot site
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 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] -- 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: How will you be able to grab that information from the logs, so I can see histories and such? I'm not going to go manually scanning logs. I want a web page that shows me the history. This is what the CI system does right now. Why would we want to reverse that? I want to be able to graph the times to look for aberrations I guess you can write log-scanning code, but that seems to be longer than the 19 extra lines that would be in the script for cruise control... OK. At least now I see a difference. You think about web-interface primary but I about notification interface. In both cases to define the reason of failure you should scanning logs but to see the 'current state' web interface more convenient. At nearest time I will experiment with both systems to define the best one and share results. thanks, Vladimir geir thanks, Vladimir Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it geir - 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]
Re: [drlvm][jit] Internal testing framework for Jitrino.OPT compiler
Ivan, I've checked all of the tests - this is very good beginning! I see 2 directions to advance: 1) Integrate Jitrino tests into common harmony test system. So we can ask people to use our test suite. 2) Start to test not only CFG but more complex IR examples. I mean to test IR with instructions using optimizations. I want to get item 1 as TODO for myself. Could you take item 2 and write several IR templates with instructions and use these templates in tests? getNodeCountTest2 - this is a real bug. This bug does not affect any of JIT algorithms today, but anyway it must be fixed. Could you create and post the fix into JIRA? If you have questions I can help you with the fix. On 9/26/06, Ivan Kollegov [EMAIL PROTECTED] wrote: Hello. The documentation has helped me to write the tests. I have written 4 templates of graphs and 20 tests for methods of ControlFlowGraph. I have founded a problem with test getNodeCountTest2. If there are no nodes in graph I have follows java.exe has encountered a problem and needs to close. We are sorry for the inconvenience. You can find all my test there http://issues.apache.org/jira/browse/HARMONY-1531 Can you check if these tests are OK? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
[classlib] yoko updated
Yoko version has been updated. You have to 'rm depends/jars/yoko/yoko.jar' and re-run the 'ant fetch-depends' target (or else the build complains about an MD5 failure). I'll move the Yoko JARs download into version-specific directory. Regards, Tim -- 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: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Ignore this build break, I was updating the dependencies at the time. Tim Apache Harmony Build wrote: snip [exec] -check: [exec] [echo] Checking for depends/jars/yoko-m1/yoko.jar [exec] BUILD FAILED [exec] /home/hybld/continuum-working-directory/6/classlib/build.xml:154: The following error occurred while executing this line: [exec] /home/hybld/continuum-working-directory/6/classlib/make/build-test.xml:124: The following error occurred while executing this line: [exec] /home/hybld/continuum-working-directory/6/classlib/make/depends.xml:36: The following error occurred while executing this line: [exec] /home/hybld/continuum-working-directory/6/classlib/make/depends.xml:202: ... [exec] Missing dependency. The jar from: [exec] http://people.apache.org/maven-snapshot-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M1-SNAPSHOT/yoko-spec-corba-1.0-incubating-M1-20060925.152805-4.jar [exec] should be downloaded to: [exec] depends/jars/yoko-m1/yoko.jar [exec] Run ant fetch-depends to automatically fetch dependencies. [exec] Note: Some of Harmony's dependencies are licensed under terms other [exec] than the Apache License v2. [exec] Total time: 6 seconds [echo] Tests.failed is set to true [exec] Result: 1 -- 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: [drlvm][classlib] thread library - let there be one!
+1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. Portlib function table - let there be one! Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: Weldon, I agree with your comments and observations below. Let's take baby steps to get fully unified. I'm sure we all want to keep things working throughout. So what's the first stop? Move hythread as-is out of classlib to a peer in the tree? I can suggest the following steps: - pull out hythread from classlib, make it a shared component - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread - migrate DRLVM's thread manager to (1) from APR Each step can be done without breaking the whole code stack. As a result, we'll have a bottom part of hythread which will be shared between the classlib and DRLVM. Some additional steps could be: - pull the rest of the portlib out of the classlib, make it a shared component as well - migrate DRLVM to portlib Thanks, Andrey. geir Regards, Tim Weldon Washburn wrote: On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Artem Aliev wrote: Gier, The hythread is just most visible example. There are also signal handling problem. classlib hysig lib setup signal handlers and then drlvm overrides them by its owns. There are code duplication in classlib hyprt.dll drlvm port.lib: classlib/trunk/modules/luni/src/main/native/port vm/port/src These three pair of components contains significant part of the system dependent code for both VM and CLASSLIB. I think, all this code naturally defines portlib component that could be shared between classlib and VMs. So, as a first step, we could move all this code in to the one place, name portlib to have three directories classlib, drlvm, portlib. I think it is quite reasonable to call out the portlib and threadlib separate (in the repository) to the VM and classlib. As you point out, then VM and classlib can share the code -- though it will not become a requirement for VMs that run the harmony code to be using those libraries for their own implementation. Tim, One of the things to worry about is system-wide lock protocol. We will need to think through what locks portlib, threadlib and JVM are holding and if there are any deadlock possibilities. Another issue is the implementation of signal chaining. There seems to be code in hysignal.c that implement -Xrs. I guess the idea is that a Harmony JVM would somehow not link this code and use its own implementation. The bottom line is that we probably need to carefully pick through what is currently in classlib threads/signals and rearrange stuff so that it reduces the confusion. We need to make this part of the system much easier to work on. Do you have recommendations on next steps? Does it make sense to start moving stuff into the directories described above. Or is more discussion needed. As the second step, the pairs of libraries should be merged and the classlib and drlvm refactoried to have only 3 lib instead of 6. Yep, this would be part of the consolidation into new Harmony top- level components. It makes sense that we share the same impl in the project. The 3rd step is to replace most of the functions with APR ones and move the rest of the code to the APR. I think it is quite well documented on this list that this should not be a goal. I agree we don't need to move classlib to APR provided that: 1) There is an easy to understand distinct seperation of the different threading/signals packages. In specific, we need to know which threading package is being called by DRLVM without ambiguity. 2) There is clear understanding of how JVM and classlib threading/ signals interoperate. Regards, Tim Thoughts? Thanks Artem On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: All, we need to put this issue to bed, as we're tripping over it, it seems. Any thoughts on how to move forward on this? 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
Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
gpProtectedMain() is in classlib/trunk/modules/luni/src/main/native/launcher/shared/main.c signalProtectedMain() is in classlib/trunk/modules/luni/src/main/native/launcher/shared/cmain.c Incidentally, I am noticing that portlib gets initialized with a default copy of MasterPortLibraryTable from portpriv.h. This could be causing all kinds of undefined behavior. I think shortly after hyport_create_library() is called, we should re-write the functions to point into DRLVM thread manager. Andrey Chernyshev -- what do you think? On 9/26/06, Leo Li [EMAIL PROTECTED] wrote: Hi, Weldon: Which file includes signalProtectMain() or gpProtectedMain ? :) On 9/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: It looks like hysignal.c is using the right monitor enter/exit(). That is, the one from drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/hythr.dll However, a bunch of functions in classlib's hysignal.c have an incoming argument of HyPortLibrary *portlib. The portlib variable can either point to the original classlib portlib C struct. Or it can point to PORTLIB which is a C struct with all the entries nulled out (more on this later.) I think the next question to ask is what hysignal.c does with the HyPortLibrary *portlib argument. If anyone knows, please tell us. Otherwise I will keep digging. From stepping through DRLVM bootup, it looks like classlib's portlib is _dropped_ in signalProtectMain(). Then launcher gpProtectedMain calls invocation(PORTLIB,...) where PORTLIB is a nulled out HyPortLibrary C struct. We need to put comments in the code describing the switch from classlib's portlib to drlvm's nulled out version. On 9/22/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, Its not clear at this moment what threading implementation is being executed when hysignal.c calls hythread_monitor_enter(). If someone already knows, please tell us. Otherwise, I will step through it with the debugger to find out what is going on. - Weldon -- Weldon Washburn Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division -- Leo Li China Software Development Lab, IBM -- Weldon Washburn Intel Middleware Products Division
Re: Can't unsubscribe...
Geir: I've been trying to unsub for a while too. Nothing seems to work. Would you mind unsubbing [EMAIL PROTECTED] from the Harmony and JIRA lists? It's been a trip. Many Thanks. Phil Forestall 'Never trust a computer too big to throw out of a window.' - Paul Allen From: Geir Magnusson Jr. [EMAIL PROTECTED] Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org CC: [EMAIL PROTECTED] Subject: Re: Can't unsubscribe... Date: Sat, 23 Sep 2006 16:55:31 -0400 Done geir On Sep 23, 2006, at 4:52 PM, Fernando Cassia wrote: this one... [EMAIL PROTECTED] I find myself erasing messages all the time... (my 2.5gb space is at 99%).. and the ones to blame for that are the two dozen mailing lists I've subscribed to... :-) Thanks FC On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: Help... I need to move my mailing list subscriptions from this email address to another. I emailed the unsubscribe address shown at the footer of every message, but so far it doesn seem to have worked. Any ideas/suggestions? (please refrain from saying throw your computer off a cliff ;-). Is this a join if you wish, leave if you can kind of mailing list?. ;-) FC - 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] -- When I do good, I feel good; when I do bad, I feel bad. That's my religion. - Abraham Lincoln. I do not believe in the immortality of the individual, and I consider ethics to be an important but exclusively human concern, without any supernatural authority behind it. - Albert Einstein. - 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: Can't unsubscribe...
done On Sep 27, 2006, at 2:05 PM, Phil Forestall wrote: Geir: I've been trying to unsub for a while too. Nothing seems to work. Would you mind unsubbing [EMAIL PROTECTED] from the Harmony and JIRA lists? It's been a trip. Many Thanks. Phil Forestall 'Never trust a computer too big to throw out of a window.' - Paul Allen From: Geir Magnusson Jr. [EMAIL PROTECTED] Reply-To: harmony-dev@incubator.apache.org To: harmony-dev@incubator.apache.org CC: [EMAIL PROTECTED] Subject: Re: Can't unsubscribe... Date: Sat, 23 Sep 2006 16:55:31 -0400 Done geir On Sep 23, 2006, at 4:52 PM, Fernando Cassia wrote: this one... [EMAIL PROTECTED] I find myself erasing messages all the time... (my 2.5gb space is at 99%).. and the ones to blame for that are the two dozen mailing lists I've subscribed to... :-) Thanks FC On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: Help... I need to move my mailing list subscriptions from this email address to another. I emailed the unsubscribe address shown at the footer of every message, but so far it doesn seem to have worked. Any ideas/suggestions? (please refrain from saying throw your computer off a cliff ;-). Is this a join if you wish, leave if you can kind of mailing list?. ;-) FC --- -- 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] -- When I do good, I feel good; when I do bad, I feel bad. That's my religion. - Abraham Lincoln. I do not believe in the immortality of the individual, and I consider ethics to be an important but exclusively human concern, without any supernatural authority behind it. - Albert Einstein. - 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] - 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-1582 - invocation API for DRLVM
On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Are there any known design flaws in it? I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? -- Weldon Washburn Intel Middleware Products Division
Re: [jira] Created: (HARMONY-1609) Applet, ImageIO and Print modules
Woo hoo! Good work Alexey and team. Tim Alexey Petrenko (JIRA) wrote: Applet, ImageIO and Print modules - Key: HARMONY-1609 URL: http://issues.apache.org/jira/browse/HARMONY-1609 Project: Harmony Issue Type: New Feature Components: Classlib, Contributions Reporter: Alexey Petrenko Attachments: apio.zip This contribution consists of Applet, ImageIO and Print modules implementation and tests. It also adds few classes to awt and swing modules which are depends on this modules. -- 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: Wonka, Mika, and Apache
great interest Chris -- let's get the wheels moving. Regards, Tim Chris Gray wrote: Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- 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: [DRLVM] (JIRA 1580) write barrier implementation for JET
On Wednesday 27 September 2006 14:20 Egor Pasko wrote: On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: Thanks. Yes, this is supposed to be review by JIT person. On the other hand, if JIT person has better solution, GCv5 would like to use. Anyway we hope write barrier is to be functioning in the DRLVM soon. As a JIT-oriented guy, I looked through the patch. Looks good. The write barrier does NOT push an M2N frame before invoking gc_heap_slot_write_ref(), but it's OK since there will be no stack unwinding from here. I want to make sure that there are going to be no JVMTI events sent inside of gc_heap_slot_write_ref. Otherwise M2N frame is necessary to allow stack iterator to work in case a JVMTI agent calls something like GetStackTrace. Also can a hardware exception occur as a result of this helper call? Just a note. Patch uses tabs and DOS EOLs. Can we use spaces and unix line endings instead? I am curious about the switch VM_Global_State::loader_env-use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? On 9/27/06, Weldon Washburn [EMAIL PROTECTED] wrote: It would probably be best if a JIT person committed this patch. Maybe Stephan Mishura? If its not committed soon, bug me and I will do it. On 9/26/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write barrier implementation for JET that GCv5 is going to use (it doesn't impact anything else). It would be great if some commiter can help to review and commit it. Thanks. -xiaofeng http://issues.apache.org/jira/browse/HARMONY-1580?page=all The patch is against revision revision 442796. Repeat the desciption of the patch: Attached patch is an implementation of write barrier for JET compiler of DRLVM. The patch lets JET to call gc_requires_barriers() of GC to determine if it needs to insert the write barrier code into the jitted code, so it doesn't impact current DRLVM/GC at all. It calls gc_heap_slot_write_ref( ) of GC module, which takes three parameters. The signature is void gc_heap_slot_write_ref (Managed_Object_Handle p_obj_holding_ref,Managed_Object_Handle *p_slot, Managed_Object_Handle p_target). The patch is based on revision 442796. We hope it can be committed to Harmony soon because GCv5 will be depending on it. We don't use existing getaddress__gc_write_barrier_fastcall () in DRLVM because it only remembers object rather than the slot, and the name is not descriptive. But we may use it later. Thanks. -- 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]
Re: [drlvm] [launcher] Executable hangs
Hmm never saw it hanging at this point. It looks like a java class loader starts on loading a j.l.Thread class and somehow deadlocks or waits for something. I would try to get a stack trace in the first place, evaluating st_print() in debugger but it doesn't always work correctly. Can anyone else suggest a way to debug this problem? On Wednesday 27 September 2006 09:35 Armand Navabi wrote: Gregory Shimansky wrote: I think not. DRLVM needs its own threading library. The reason is discussed in a separate thread thread library - let there be one. I am not sure I understand all the reasoning for separate libhythr.so implementation, but I know the drlvm version should be in bin/ and bin/default/ directories. Ok, I read that thread. Is there an easy temporary fix to this? What is the reason to set breakpoint in jni.cpp:478? It is a condition that if JNI FindClass is called in exception state it shouldn't do anything, just return NULL. I'm sorry, my line 478 is different than yours, because I have other prints and things in there. I was not putting the breakpoint on the line that checks if it is called in exception state. Basically, I just put a print inside of that procedure because I traced the hanging to that method (or so I thought). My point was that I am unable to breakpoints anywhere in jni.cpp. Below you have explained what problem that is related to. And as far as tracing, you have suggested a much more efficient way to trace where it is going in the code. Thanks. Make breakpoint pending on future shared library load? (y or [n]) y And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. The solution for this was found and discussed in thread APR fails to load a JIT library when using a fully qualified path. The launcher execs itself with a new environment setting for LD_LIBRARY_PATH and gdb cannot work around this. I reread those threads and it seems some changes were suggested. Have these changes been made. I couldn't see (or perhaps couldn't figure out) any way to quickly fix this from the discussions. It seemed as though people were suggesting moving and merging libraries. If it has been fixed, I should have it because I have recently updated. I have a proposal for you. Run java -Xthread -Xtrace Hello for hello world application. The -Xtrace option will produce a lot of output but it will enable all debugging tracing in drlvm and when it hangs for you it will be a very close location to the reason of the problem. If there is no output with -Xtrace, then it probably means launcher problems. Please update the sources, some launcher problems were resolved just recently I updated all the classlib and drlvm code earlier today. Just to make sure we are talking about the same thing here, I have compiled helloworld.java separately with Sun's compiler and then I made sure it ran (it runs both with Sun's java and the classlib with IBM's VM), and then I moved it to the drlvm's bin directory. There is no particular Hello application you are talking about correct? The application I am running was a java program I wrote myself and compiled. And then I tried to run my hello world application as you said. Like you said it produced a lot of output and towards the end when it hanged, this is the last output it produced: [0x4000] : Looking for native: java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I [0x4000] : trying: Java_java_lang_VMThreadManager_start [0x4000] : Compiled method java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I, entry 0xb68a4000 [0x4000] : GetObjectClass called [0x4000] : GetObjectClass: class = java/lang/FinalizerThread [0x4000] : GetFieldID called [0x4000] : GetFieldID java/lang/FinalizerThread.vm_thread J = 0x8286894 [0x4000] : GetLongField called, id = 0x8286894 [0x4000] : IsInstanceOf called [0x4000] : GetObjectClass called [0x4000] : GetObjectClass: class = java/lang/FinalizerThread [0x8003] : gc_thread_init 0x807d720 [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 0x8633a18 [0x8003] : 0x8633a18 0x807d660 I java/lang/Thread [0x8003] : Loader U (0x8633a18) loading class: java/lang/Thread... [0x8003] : enter method java/lang/ClassLoader loadClass (Ljava/lang/String;)Ljava/lang/Class; At this point, it hangs, and I am forced to Cntrl^c to kill the process. Thanks, Armand
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
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]
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
On 9/28/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Wednesday 27 September 2006 14:20 Egor Pasko wrote: On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: Thanks. Yes, this is supposed to be review by JIT person. On the other hand, if JIT person has better solution, GCv5 would like to use. Anyway we hope write barrier is to be functioning in the DRLVM soon. As a JIT-oriented guy, I looked through the patch. Looks good. The write barrier does NOT push an M2N frame before invoking gc_heap_slot_write_ref(), but it's OK since there will be no stack unwinding from here. I want to make sure that there are going to be no JVMTI events sent inside of gc_heap_slot_write_ref. Otherwise M2N frame is necessary to allow stack iterator to work in case a JVMTI agent calls something like GetStackTrace. No, stack should never be examined in write barrier. That's completely contridicting the purpose of write barrier. Thanks, xiaofeng - 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] (JIRA 1580) write barrier implementation for JET
On 27 Sep 2006 17:20:36 +0700, Egor Pasko [EMAIL PROTECTED] wrote: I am curious about the switch VM_Global_State::loader_env-use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? The LIL stub has been tested. It is there as a place holder for future write barrier optimizations. Thanks, xiaofeng - 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] (JIRA 1580) write barrier implementation for JET
Thanks to Egor and Gregory's responses to the JET write barrier patch. Those help. I was away from JIT development for a while. :-) Since the patch is small, if needed, please feel free to modify it as a JIRA update, or a committer to merge it then we submit new patch later. Basically the write barrier should be as small (quick) as possible and involves no additional VM runtime operations. A view to write barrier can be that, it is only an extended bytecode of the orignal reference store one. That means, we can implement it in anyway appropriate as long as the semantics of the reference store is kept, either in JIT IR, in LIL, in asm or as a function call. Performance and flexibility are the main goals. The performance is easy to understand, the flexibility refers to that a GC developer probably can conveniently change the write barrier implementation. As I know, a volunteer (Mikhail Fursov?) is writing helper inlining for DRLVM. Hopefully that will be the ultimate solution for write barrier implementation. Before that is ready, an intermediate solution would be acceptable. Thanks, xiaofeng On 27 Sep 2006 17:20:36 +0700, Egor Pasko [EMAIL PROTECTED] wrote: I am curious about the switch VM_Global_State::loader_env-use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? - 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] fail statements omitted in many exception catching test cases
Great Mark!
I've merged your code into my script. The script can be downloaded at [1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED] wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases about
excep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the
exception
-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of
our Har
mony classlib. So I set some rules to find out all lines of code related
with
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules
in r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of
above s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileIn
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind
without
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those
bugs? Pl
s. share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterTest.java
:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI=
nputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallba=
ckTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTe=
st.java:60
.\auth\src\test\java\common\javax\security\auth\kerberos\ServicePermissionT=
est.java:302
.\auth\src\test\java\common\javax\security\auth\PolicyTest.java:132
.\auth\src\test\java\common\javax\security\auth\PrivateCredentialPermission=
Test.java:267\386
Re: [classlib][test] fail statements omitted in many exception catching test cases
Thanks for checking the result and working on it. I put the result on Harmony wiki[1], anyone is welcome to check the result to find some bugs. [1]:http://wiki.apache.org/harmony/failstatementsomitted On 9/27/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Robert, Nice work! I've checked the entries for classes from the beans module. It seems you found at least three bugs in tests for beans: Bugs: .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextServicesSupportTest.java:739 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:1388 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:449 Valid: .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\beancontext\BeanContextSupportTest.java:234\251 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\IntrospectorTest.java:1266\1304 needs more investigation .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\StatementTest.java:93 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLDecoderTest.java:92 .\beans\src\test\java\org\apache\harmony\beans\tests\java\beans\XMLEncoderTest.java:334 Thank you for this. I will file corresponding JIRA. Regards, snip -- Robert Hu China Software Development Lab, IBM
Re: [classlib][test] fail statements omitted in many exception catching test cases
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu [EMAIL PROTECTED] wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at [1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED] wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases about
excep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the
exception
-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of
our Har
mony classlib. So I set some rules to find out all lines of code related
with
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules
in r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of
above s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.java:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTest.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileIn
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\FileOu
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind
without
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those
bugs? Pl
s. share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl=
aterTest.java
:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI=
nputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallba=
ckTest.java:60\147
.\auth\src\test\java\common\javax\security\auth\callback\LanguageCallbackTe=
st.java:60
Re: [classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
On 9/27/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff src.length || dstOff dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
Hello Denis,
According to our Compatibility Guidelines[1], I suggest we follow RI
for this issue though you may feel uncomfortable about the additional
code ;-)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Best regards,
Richard
2006/9/27, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[], int,
int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number of
points to transform is zero. Harmony doesn't throw any exception. Spec doesn't say
about any exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation
doesn't use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown
Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
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]
--
Richard Liang
China 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: [DRLVM] (JIRA 1580) write barrier implementation for JET
On 9/27/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Thanks to Egor and Gregory's responses to the JET write barrier patch. Those help. I was away from JIT development for a while. :-) Since the patch is small, if needed, please feel free to modify it as a JIRA update, or a committer to merge it then we submit new patch later. Basically the write barrier should be as small (quick) as possible and involves no additional VM runtime operations. A view to write barrier can be that, it is only an extended bytecode of the orignal reference store one. That means, we can implement it in anyway appropriate as long as the semantics of the reference store is kept, either in JIT IR, in LIL, Please no LiL. We need to replace LiL code with either Java/vmmagic, jit intrinsic or emitter based asm code. Even JIT IR would be preferable to LiL. in asm or as a function call. Performance and flexibility are the main goals. The performance is easy to understand, the flexibility refers to that a GC developer probably can conveniently change the write barrier implementation. As I know, a volunteer (Mikhail Fursov?) is writing helper inlining for DRLVM. Hopefully that will be the ultimate solution for write barrier implementation. Before that is ready, an intermediate solution would be acceptable. Thanks, xiaofeng On 27 Sep 2006 17:20:36 +0700, Egor Pasko [EMAIL PROTECTED] wrote: I am curious about the switch VM_Global_State::loader_env-use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [general] jre and hdk snapshots posted to general snapshot site
On 9/27/06, Alexei Zakharov [EMAIL PROTECTED] wrote: 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. It is just other use case. If nobody objects I'll prepare patches for it. thanks, Vladimir 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] -- 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: [doc] new Getting Started guides
On 9/22/06, Geir Magnusson Jr. wrote: As discussed earlier today, there are now two new Getting Started guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... Hi Geir, It is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
This did not seem to solve the problem. It does not successfully put a break in main.c (says no source file main.c). [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ gdb ./java GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) break main.c:360 No source file named main.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) show environment ... LD_LIBRARY_PATH=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/ ... JAVA_HOME=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre ... I am able to do break main, but I tried to do what you have explained below (i.e. break somewhere after libjitrino.so is loaded), but it says compile_jit_a_method is not defined. Thanks, Armand Egor Pasko wrote: I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put somewhere in ~/.gdbinit, two scripts are better: first for initial run, the second script does the same but reusing old breakpoint numbers: dis en 1 r dis en 2 c dis I should put that into the FAQ, obviously. And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. this one is probably a separate issue (not connected with future shared library load). Try my above suggestion, please. GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11007)] [New Thread 32769 (LWP 11010)] [New Thread 16386 (LWP 11011)] Cannot find thread 32769: invalid thread handle (gdb) q The program is running. Exit anyway? (y or n) y [1]+ Stopped gdb ./java Thanks, Armand On the 0x1F0 day of Apache Harmony Armand Navabi wrote: When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to find when it hangs. I see the following: Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Also, when I run ./java -Xtrace:em, I get the following (and it hangs): ... EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Again, it seems to always hang after FindClass is called for java/lang/Thread. I have tried setting LD_LIBRARY_PATH as suggested earlier. I also have JAVA_HOME set (and I have tried it with it unset). Everything seems to have the same behavior. [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/ homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/ default [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre I am using Gentoo Linux. Any ideas? Thanks, Armand Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux
Re: [drlvm] [launcher] Executable hangs
On the 0x1F2 day of Apache Harmony Armand Navabi wrote:
This did not seem to solve the problem. It does not successfully put a
break in main.c (says no source file main.c).
Oops, some day I made everything build in debug mode locally. And
forgot about it. Currently there is no option for that. TBD,
obviously. I do it with the patch (linux only) like this:
Index: working_vm/build/build.sh
===
--- working_vm/build/build.sh (revision 449589)
+++ working_vm/build/build.sh (working copy)
@@ -80,6 +80,6 @@
# it is necessarily to compile 'vm.jitrino' in release mode
-$ANT_COMMAND -f ./make/build.xml -Dvm.jitrino.cfg=release $@ || ERROR
+$ANT_COMMAND -f ./make/build.xml $@ || ERROR
Index: working_vm/build/make/components/vm/jitrino.xml
===
--- working_vm/build/make/components/vm/jitrino.xml (revision 449589)
+++ working_vm/build/make/components/vm/jitrino.xml (working copy)
@@ -25,7 +25,7 @@
--
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends value=extra.apr,vm.vmcore,vm.encoder
/
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -50,7 +50,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+!-- compiler name=${build.cxx} id=cpp.compiler --
+compiler id=cpp.compiler extends=common.cpp.compiler
fileset dir=${src}
include name=dynopt/*.cpp /
include name=main/*.cpp /
Index: working_vm/build/make/targets/common_vm.xml
===
--- working_vm/build/make/targets/common_vm.xml (revision 449589)
+++ working_vm/build/make/targets/common_vm.xml (working copy)
@@ -105,6 +105,8 @@
select cfg=debug
compilerarg value=-O0 /
+compilerarg value=-g /
+compilerarg value=-ggdb3 /
/select
/select
Index: working_classlib/depends/build/makefile.include
===
--- working_classlib/depends/build/makefile.include (revision 448846)
+++ working_classlib/depends/build/makefile.include (working copy)
@@ -28,5 +28,5 @@
DLLPATH=$(HY_HDK)/jdk/jre/bin/
SHAREDSUB=../shared/
-CFLAGS = -O1 $(HY_CFLAGS) -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT \
+CFLAGS = -O0 -g $(HY_CFLAGS) -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT \
-D$(HY_ARCH_DEFINE) $(VMDEBUG) -I$(HY_HDK)/include
-I$(HY_HDK)/jdk/include -I. -I$(SHAREDSUB)
Guys, I hope someone finishes that into a final solution so we can put
that to SVN. Most likely, I'll do that, when I am done with fixing
Jitrino.OPT to run the ClassLoaderTest. Any volunteering is, as
always, welcome))
[EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ gdb
./java
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i686-pc-linux-gnu...Using host libthread_db
library /lib/libthread_db.so.1.
(gdb) break main.c:360
No source file named main.c.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) show environment
...
LD_LIBRARY_PATH=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
...
JAVA_HOME=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre
...
I am able to do break main, but I tried to do what you have explained
below (i.e. break somewhere after libjitrino.so is loaded), but it says
compile_jit_a_method is not defined.
Thank you for digging into it. That's really valuable. I hope we will
fix the issue soon.
Thanks,
Armand
Egor Pasko wrote:
I solve this by breaking inside launcher after VM lib is loaded, then
I break somewhere after libjitrino.so is loaded. Then I can break
anywhere :)
looks like this:
break main.c:360
r
dis
break compile_jit_a_method
c
dis
break whatever function you want
You can make it a script via GDB's 'define' and put somewhere in
~/.gdbinit, two scripts are better: first for initial run, the second
script does the same but reusing old breakpoint numbers:
dis
en 1
r
dis
en 2
c
dis
I should put that into the FAQ, obviously.
And then when I run the program it never stops at the breakpoint, though I
see the print I have inserted in the code.
[vm] IBM VME related issues
Here is the list of JIRA issues which should not slip attention of IBM engineers: HARMONY-1596 HARMONY-1309 HARMONY-813 These are just the ones I'm aware of, please extend this list if you know some :) -- Regards, 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: [doc] new Getting Started guides
Fixed. Thanks. No, you weren't being too picky - you were right on :) geir On Sep 27, 2006, at 8:44 AM, Sian January wrote: Hi Geir, Those new documents look really good. I just found a few spelling mistakes on the first one (http://incubator.apache.org/harmony/ quickhelp_users.html). In the first paragraph no development tools our need to should probably be no development tools or need to. In the fourth paragraph run well on the paltforms offered should be run well on the platforms offered and in the fifth paragraph I think unpack inÄto a jre directory should be unpack into a jre directory. I hope you don't think I'm being picky - I just think it's better for the project's image if we have correct spelling and grammar etc on the website. Thanks, Sian On 22/09/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As discussed earlier today, there are now two new Getting Started guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... geir - 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] -- Sian January 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: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
You should guess where... On Sep 27, 2006, at 9:51 AM, Denis Kishenko wrote: I should guess 2006/9/27, Geir Magnusson Jr. [EMAIL PROTECTED]: I have a tattoo. geir On Sep 27, 2006, at 8:52 AM, Denis Kishenko wrote: do you wear such one =) 2006/9/27, Geir Magnusson Jr. [EMAIL PROTECTED]: you can wear it too if you want. either share with Vladimir, or make your own copy :) On Sep 27, 2006, at 8:39 AM, Denis Kishenko wrote: Vladimir, my congratulations! 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: Thanks :) On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Here's a badge for you to cut out and wear g +-+ | Harmony | | Champion! | +-+ Keep up the good work! Regards, Tim Vladimir Ivanov wrote: It is my 200 issue in Harmony. Seems, I'm the champion :) -- Forwarded message -- From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED] Date: Sep 25, 2006 7:50 PM Subject: [jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run To: [EMAIL PROTECTED] [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run - -- Key: HARMONY-1569 URL: http://issues.apache.org/jira/browse/ HARMONY-1569 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Vladimir Ivanov Now, the system JAVA_HOME variable is used. The value should point to tested runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- Denis M. Kishenko Intel Middleware Products Division - 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] -- Denis M. Kishenko Intel Middleware Products Division - 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 27, 2006, at 10:12 AM, Vladimir Ivanov wrote: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: How will you be able to grab that information from the logs, so I can see histories and such? I'm not going to go manually scanning logs. I want a web page that shows me the history. This is what the CI system does right now. Why would we want to reverse that? I want to be able to graph the times to look for aberrations I guess you can write log-scanning code, but that seems to be longer than the 19 extra lines that would be in the script for cruise control... OK. At least now I see a difference. You think about web-interface primary but I about notification interface. No. i think about the data. The fact that I use a web interface to look at that data is irrelevant. As to notification, we can program the thing to do any behavior you want. There's no need to require a 1:1 mapping of notification behavior to build target in classlib. In both cases to define the reason of failure you should scanning logs but to see the 'current state' web interface more convenient. At nearest time I will experiment with both systems to define the best one and share results. thanks, Vladimir geir thanks, Vladimir Maybe I'm misunderstanding your motivation? Having that target in classlib is fine. But I can't see why we'd ever want to use it in the context that we are discussing it 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: [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]
Re: [general] jre and hdk snapshots posted to general snapshot site
On Sep 27, 2006, at 10:16 AM, Alexei Zakharov wrote: If we plan to use HDK for supporting developers who work on single module (that is a good idea IMHO) That was one of the originally stated motivations, yes. 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. Something like that, yes. geir 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: 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] -- 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] - 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][classlib] thread library - let there be one!
On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/something is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. Is there any downside to keeping it somewhere under /classlib/trunk and simply make it a module by itself? Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. Portlib function table - let there be one! Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: Weldon, I agree with your comments and observations below. Let's take baby steps to get fully unified. I'm sure we all want to keep things working throughout. So what's the first stop? Move hythread as-is out of classlib to a peer in the tree? I can suggest the following steps: - pull out hythread from classlib, make it a shared component - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread - migrate DRLVM's thread manager to (1) from APR Each step can be done without breaking the whole code stack. As a result, we'll have a bottom part of hythread which will be shared between the classlib and DRLVM. Some additional steps could be: - pull the rest of the portlib out of the classlib, make it a shared component as well - migrate DRLVM to portlib Thanks, Andrey. geir Regards, Tim Weldon Washburn wrote: On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Artem Aliev wrote: Gier, The hythread is just most visible example. There are also signal handling problem. classlib hysig lib setup signal handlers and then drlvm overrides them by its owns. There are code duplication in classlib hyprt.dll drlvm port.lib: classlib/trunk/modules/luni/src/main/native/port vm/port/src These three pair of components contains significant part of the system dependent code for both VM and CLASSLIB. I think, all this code naturally defines portlib component that could be shared between classlib and VMs. So, as a first step, we could move all this code in to the one place, name portlib to have three directories classlib, drlvm, portlib. I think it is quite reasonable to call out the portlib and threadlib separate (in the repository) to the VM and classlib. As you point out, then VM and classlib can share the code -- though it will not become a requirement for VMs that run the harmony code to be using those libraries for their own implementation. Tim, One of the things to worry about is system-wide lock protocol. We will need to think through what locks portlib, threadlib and JVM are holding and if there are any deadlock possibilities. Another issue is the implementation of signal chaining. There seems to be code in hysignal.c that implement -Xrs. I guess the idea is that a Harmony JVM would somehow not link this code and use its own implementation. The bottom line is that we probably need to carefully pick through what is currently in classlib threads/signals and rearrange stuff so that it reduces the confusion. We need to make this part of the system much easier to work on. Do you have recommendations on next steps? Does it make sense to start moving stuff into the directories described above. Or is more discussion needed. As the second step, the pairs of libraries should be merged and the classlib and drlvm refactoried to have only 3 lib instead of 6. Yep, this would be part of the consolidation into new Harmony top- level components. It makes sense that we share the same impl in the project. The 3rd step is to replace most of the functions with APR ones and move the rest of the code to the APR. I think it is quite well documented on this list that this should not be a goal. I agree we don't need to move classlib to APR provided that: 1) There is an easy to understand distinct seperation of the different threading/signals packages. In specific, we need to know which threading package is being called by DRLVM without ambiguity. 2) There is clear understanding of how JVM and classlib threading/ signals interoperate. Regards, Tim Thoughts? Thanks Artem On 9/19/06, Geir Magnusson Jr.
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
On Sep 27, 2006, at 4:04 PM, Weldon Washburn wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. It's not IBM's threading library. It's Harmony's threading library. :) 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] HARMONY-1582 - invocation API for DRLVM
On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. Weldon, I completely agree with what your are saying. It's common problem of current hythread that should be resolved some how. I just go inline with current implementation and added two missing functions. Missing these can lead to the same problems as with hythread_exit discussed in another thread [drlvm] [launcher] Executable hangs. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Only me and you :-) Honetsly I think it happpens now Are there any known design flaws in it? I can think of two possible problems we may want to discuss. 1) Should native threads have daemon status or its completely java notion? This is TM related thing. 2) Should we attach thread to VM before attaching it to TM by calling jthread_atatch OR jthread_attach should callback VM to attach a thread to it? I didn't change original design of TM here .. it implements second choice. I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? No, this is not just different names. tm_suspend_enable asserts that thread is in disabled state before calling hythread_suspend_enable (in debug mode only). Thanks Evgueni -- Weldon Washburn 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: [doc] new Getting Started guides
On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote: t is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. I understand. Remember, this is targetted for newbies - people who don't know anything yet, and what it tries to do is find the fastest path to getting working code from a single checkout. We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. Good point. But what other components right now would you point to? BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? No. There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile. I think we need to continue to focus on our primary goal, java SE. I've also been concerned about having subprojects that are too independent, creating sub-communities. I think that should be avoided at all cost. Sure, we each have our focus and specialization, but we're one project, one community. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... As for homepages, we already have that - basic pages for each major component. geir Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
On our way to tools... +1 from Nathan, Paulex, Alexey, Salikh, Oleg, geir, Ilya, Tim, Mark Stepan done... On Sep 24, 2006, at 10:43 PM, Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. Please vote to accept or reject this contribution into the Apache Harmony project : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. 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: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
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]
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
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
[vote] HARMONY-1410 : JDWP agent for DRLVM
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]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 from me On Sep 28, 2006, at 1:38 AM, Geir Magnusson Jr. wrote: 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]
[classlib][test]Deal with un-deleted temp files created in tests
Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that Note zfile is a user-defined zip file used by other tests and should not be deleted, it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory org\apache\harmony\jndi\tests\javax\naming\spi with a file jndiprovider.properties and a sub directory mock. This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! -- Best Regards! Jimmy, Jing Lv 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]
