[classlib][luni]To open warning as error on Linux
Hi, all I plan to give a patch that fixed all warning in native code of luni on Linux and then set Werror in luni makefile. But now I have a problem: Different versions of gcc have different definitions of warnings, for example, the file can build on my default GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set warning as error on. Although I can fix it on GCC4.0.3, what about other versions? So my question is whether we have our default or reference version of GCC?:) -- Leo Li China Software Development Lab, IBM
Re: [classlib][luni]To open warning as error on Linux
If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li [EMAIL PROTECTED]: Hi, all I plan to give a patch that fixed all warning in native code of luni on Linux and then set Werror in luni makefile. But now I have a problem: Different versions of gcc have different definitions of warnings, for example, the file can build on my default GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set warning as error on. Although I can fix it on GCC4.0.3, what about other versions? So my question is whether we have our default or reference version of GCC?:) -- Leo Li China Software Development Lab, IBM -- 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] Cleaning insides of Class.h header
It is the revision from saturday, september, 23rd. Regards, Pavel. On 9/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: Pavel, I glanced at it. Was this patch made on an svn revision number from this week? On 9/23/06, Pavel Pervov [EMAIL PROTECTED] wrote: Created Harmony-1558 [1] with the intention to attach all patches to it. Step 1 patch attached - interested parties can review. Regards, Pavel. [1] https://issues.apache.org/jira/browse/HARMONY-1558 On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote: Hello, all. I would like to work on cleaning the insides of Class.h header file. This header is related to internal representation of java class inside the VM. Currently it contains all entities for internal class representation: class itself, constant pool, members (field, method), exceptions handler, vtable and so forth. First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Second thing to do is to throw away members (and other stuff), which are not used anymore and the only reason they are still there is history or they do not belong to these files. Third thing to do is to make all these entities C++ objects. Currently, member variables of all listed entities are used arbitrarily throughout DRLVM code. I would like to regularize usage and, also, document internals of these entities. Certainly, I'll do all these changes step-by-step with little patches coming in. Regards, Pavel Pervov Intel Middleware Products Division. -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][luni]To open warning as error on Linux
It helps to maintain code with less potential problems in it. AFAIK, GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix warnings on GCC 4.x the code will compile without warnings on either version of GCC. -- Ivan On 9/25/06, Alexey Petrenko [EMAIL PROTECTED] wrote: If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li [EMAIL PROTECTED]: Hi, all I plan to give a patch that fixed all warning in native code of luni on Linux and then set Werror in luni makefile. But now I have a problem: Different versions of gcc have different definitions of warnings, for example, the file can build on my default GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set warning as error on. Although I can fix it on GCC4.0.3, what about other versions? So my question is whether we have our default or reference version of GCC?:) -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]To open warning as error on Linux
Hi, Alexey: It can help to avoid the situation that Harmony builds successfully on Linux while fails on windows since its -W3 is on as talked in such thread: http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg13806.html On 9/25/06, Alexey Petrenko [EMAIL PROTECTED] wrote: If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li [EMAIL PROTECTED]: Hi, all I plan to give a patch that fixed all warning in native code of luni on Linux and then set Werror in luni makefile. But now I have a problem: Different versions of gcc have different definitions of warnings, for example, the file can build on my default GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set warning as error on. Although I can fix it on GCC4.0.3 , what about other versions? So my question is whether we have our default or reference version of GCC?:) -- Leo Li China Software Development Lab, IBM -- 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] -- Leo Li China Software Development Lab, IBM
Re: [classlib][luni]To open warning as error on Linux
Thank you, Ivan. I will let it pass GCC4.x. On 9/25/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: It helps to maintain code with less potential problems in it. AFAIK, GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix warnings on GCC 4.x the code will compile without warnings on either version of GCC. -- Ivan On 9/25/06, Alexey Petrenko [EMAIL PROTECTED] wrote: If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li [EMAIL PROTECTED]: Hi, all I plan to give a patch that fixed all warning in native code of luni on Linux and then set Werror in luni makefile. But now I have a problem: Different versions of gcc have different definitions of warnings, for example, the file can build on my default GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set warning as error on. Although I can fix it on GCC4.0.3, what about other versions? So my question is whether we have our default or reference version of GCC?:) -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Leo Li China Software Development Lab, IBM
Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. - 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][luni]To open warning as error on Linux
Sounds reasonable. Seems the lastest version of GCC is 4.1.x[1], we may download this version and have a try :) [1]http://gcc.gnu.org/ 2006/9/25, Ivan Volosyuk [EMAIL PROTECTED]: It helps to maintain code with less potential problems in it. AFAIK, GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix warnings on GCC 4.x the code will compile without warnings on either version of GCC. -- Ivan On 9/25/06, Alexey Petrenko [EMAIL PROTECTED] wrote: If this is a potential build problem do we really need to set this option? 2006/9/25, Leo Li [EMAIL PROTECTED]: Hi, all I plan to give a patch that fixed all warning in native code of luni on Linux and then set Werror in luni makefile. But now I have a problem: Different versions of gcc have different definitions of warnings, for example, the file can build on my default GCC3.0.4 of RH but fails on GCC4.0.3 of my colleague's ubuntu if I set warning as error on. Although I can fix it on GCC4.0.3, what about other versions? So my question is whether we have our default or reference version of GCC?:) -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
It was me...the build server needs ant fetch-depends to get the jetty. I will try to recover it soon. Sorry for the inconvenience caused. Apache Harmony Build wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/5763 Build statistics: State: Failed Previous State: Ok Started at: Mon, 25 Sep 2006 09:01:37 +0100 Finished at: Mon, 25 Sep 2006 09:02:10 +0100 Total time: 33s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib/make/depends.xml classlib/make/depends.properties Output: Buildfile: build.xml build: [delete] Deleting directory /home/hybld/continuum-working-directory/6/classlib/deploy [echo] Classlib revision is 449596 [echo] Post process: true [echo] JAPI: true [echo] Building with reference jdk/javac [exec] Buildfile: build.xml [exec] clean-java: [exec] clean-bin: [exec] call-modules-all: [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 15 files from /home/hybld/continuum-working-directory/6/classlib/modules/accessibility/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 1 files from /home/hybld/continuum-working-directory/6/classlib/modules/applet/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 41 files from /home/hybld/continuum-working-directory/6/classlib/modules/archive/bin/test [exec] clean-native-includes: [exec][delete] /home/hybld/continuum-working-directory/6/classlib/deploy/include not found. [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 214 files from /home/hybld/continuum-working-directory/6/classlib/modules/auth/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 569 files from /home/hybld/continuum-working-directory/6/classlib/modules/awt/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 233 files from /home/hybld/continuum-working-directory/6/classlib/modules/beans/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] /home/hybld/continuum-working-directory/6/classlib/modules/concurrent/bin/test not found. [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 88 files from /home/hybld/continuum-working-directory/6/classlib/modules/crypto/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 20 files from /home/hybld/continuum-working-directory/6/classlib/modules/instrument/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 162 files from /home/hybld/continuum-working-directory/6/classlib/modules/jndi/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 2 files from /home/hybld/continuum-working-directory/6/classlib/modules/lang-management/bin/test [exec] clean: [exec][delete] Excludesfile /home/hybld/continuum-working-directory/6/classlib/deploy/build/patternsets/luni-kernel.txt not found. [exec][delete] Deleting 95 files from
Fwd: [testing] HARMONY-995: adding new target to builds for automatic testing
Now I install the BT infrastructure on the 2 comp's: win and linux. It is woks (with small improvements. the readme.txt was updated to describe it), but I want to discuss adding a new top-level target to the vm/API builds (for example, 'all'). This target will do nothing but depends on - for API build: all = fetch-depends + rebuild + test - for VM build: all = update + clean + build + test Seems, it will be convenient for automatic (or nightly) building and testing Harmony and, may be, newbie who want to look to what is Harmony today without documentation readingJ. If nobody objects I'll prepare patch. 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
Re: [drlvm][jit] possible ABCD bug
On the 0x1EE day of Apache Harmony Naveen Neelakantam wrote: I've been reading through the ABCD implementation in jitrino, and if I understand it correctly, I found a bug. I've attached a patch to fix it. Someone who actually understands the code should verify this. Naveen, you found a secret :) Recently, I spent some time understanding Jitrino's ABCD code too. Now it seems pretty clear, you pinpointed a bug. I did not try the patch on a strong benchmark such as DaCapo, and cannot estimate how much it can give in terms of performance. (Although, it is both a performance and correctness related fix) As you pointed out recently, checking both bounds assumes one comparison in CG. So, we won't get any performance benefit on IA-32 if we remove only one (lower or upper) bound of a 'chkbounds'. Also, did anyone ever test this ABCD pass? That's a long story. And here is the secret: Jitrino ABCD removes *only* lower bounds checks. Thus, it is useless currently. Well, this is not 100% true :) Sometimes, I saw it removing upper checks, but, probably, very obvious checks. I should have looked into the problem more thoroughly. This is a very sad story, so I decided to look what is happening. The algorithm is *not* easy to read, but what I can say for sure: * it is not the algorithm as in the original paper * it's algorithm applies some more advanced techniques (i.e. analysis of bounds of the kind A*x+B, where A and B are constants, x is a variable) and lacks them * inequality graph is not built, thus uncovering some extra limitations * the algorithm assumes all constants to be zero, when proving a check to eliminate. So, I cannot find any evidence for the algorithm to remove an upper check :( I tried the original ABCD example from the paper. And was upset almost like you :) I tried to trigger various switches, but they gave no clue, except a lot of assertions out of the blue. I ask because I've tried running it on a bidirectional bubble sort as mentioned in the original paper. The paper mentions that the pass should be able to prove all of the bounds checks in the sort method as redundant/ unnecessary. However, when I try running the abcd pass on a bidirectional bubble sort (attached), none of the bounds checks are eliminated. well, some actually are: bash$ grep We can eliminate naveen.sort.log We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau !!! We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau !!! We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau !!! We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau !!! We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau !!! We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau !!! We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau !!! We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau !!! We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau but, you see, only lower bounds! (BTW, I applied your fix, it had no influence on your specific test) ...The code was so buggy and not easy to read, so I decided to implement the original algorithm by myself :) Well, I implemented the algorithm on a given inequality graph. Tested it a bit, and became satisfied on how it works. Now I am working on the IR-to-InequalityGraph transformer. And almost implemented it. At this point there is not a lot to do there to make the code working and eliminating. But, hey, you are the first to talk about ABCD on this list! I am so glad, someone found it too. If you are interested in improving Jitrino's ABCD, I can publish my early code sketches in JIRA, so we could improve the code together ASAP. I would be glad to. What do you think? Anyway, I'll publish my results, but, maybe, a bit later and working. -- 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] my latest round of patches broke something
As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changesthe issue disappeared. Geir, could you please lookat this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and stillhave the problem, so it's not from this morning.I guess this has been masked all along by the logger problem.Noted in JIRA HARMONY-1560geirOn Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][awt] Fonts with negative size.
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite
strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds =
java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you
can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
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]
-
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]
-
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-1217 : JNI-style C header file generator (aka 'javah')
+1 On 9/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote: +1 Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. - 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] invoking non-trivial jars results in IllegalAccessError
Perfect. The key was I didn't realize the launcher added the jar to the class path. Thanks geir On Sep 24, 2006, at 11:18 PM, Alexey Varlamov wrote: This is simple now :) - it's a pity a did not look at JarRunner earlier. The launcher adds -Djava.class.path=jar, so the system classloader become aware of that path. Due to delegation model, the system classloader has precedence over MyLoader. The root cause of problem is incorrect usage of API for MyLoader - JarRunner should call public loadClass(String) instead of protected findClass(String) for MyLoader. And the access modifiers hint this ;) Actually I see no reason to deal with MyLoader at all - system classloader would do fine. -- Alexey 2006/9/25, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 24, 2006, at 8:09 PM, Gregory Shimansky wrote: On Sunday 24 September 2006 05:46 Geir Magnusson Jr. wrote: On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: Actually... This is another bug :) Oh well :) I think I've found the cause of this bug. Now what to do with it... Thanks for looking into it so fast. 1. Class Foo is loaded by org/apache/harmony/vm/JarRunner$MyLoader while Bar is loaded by java/net/URLClassLoader$SubURLClassLoader. Why? I thought they would be in the same classloader, given the fact that I fed the jar to MyLoader... 2. The comparison in Resolve.cpp:177 fails because each class loader in VM has its own table of packages and thus Foo and Bar while having the same packages in name, have different packages in terms of class loading. This results in IllegalAccessError. I am not sure what actually is wrong, #1 or #2 or both. I think all user application classes should be loaded by the same system class loader unless user specifies another one. So #1 seems to be the candidate for me. -- Gregory Shimansky, 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] - 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: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 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] my latest round of patches broke something
BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On Sep 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: Now I install the BT infrastructure on the 2 comp's: win and linux. It is woks (with small improvements. the readme.txt was updated to describe it), but I want to discuss adding a new top-level target to the vm/API builds (for example, 'all'). This target will do nothing but depends on - for API build: all = fetch-depends + rebuild + test - for VM build: all = update + clean + build + test Seems, it will be convenient for automatic (or nightly) building and testing Harmony and, may be, newbie who want to look to what is Harmony today without documentation readingJ. If nobody objects I'll prepare patch. That's fine, I think, but I'm just surprised it doesn't do that now... what does it do now? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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] my latest round of patches broke something
Under what platfrom, what build? On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
2006/9/25, Chris Gray [EMAIL PROTECTED]: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. Right! I had this in mind but forgot somehow :( -- 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]
[drlvm][gc] HARMONY-1371 applied incompletely
Geir, Ivan, just a heads-up: the patch from HARMONY-1371 was applied incompletely. The below hunk was left out (i.e. it exists in HARMONY-1371, but was not committed to SVN). Is this okay? --- vm/gc/src/init.cpp +++ vm/gc/src/init.cpp @@ -51,7 +51,7 @@ int HEAP_SIZE_DEFAULT = 256 MB; unsigned int prev_mark_phase; bool cleaning_needed = false; -int gc_algorithm = 0; +int gc_algorithm = 30; int gc_adaptive = true; int64 timer_start; int64 timer_dt; - 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] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote:
As for me (and other people) a lot of tests fail for the latest
sources (revision 449592).
I've run the build.bat clean; build.bat update; build.bat command
in compliance with comments for H-1457.
It's very strange for me it mentions here all C-unit tests work
fine. Sorry I cannot confirm this.
It certainly did on my machine after a clean - update build, and then
hung on gc.LOS.
The detailed investigation showed the patch for H-1457 is
incorrect. I've attached a patch fixing this issue.
Thanks Evgueni Brevnov for preparing this patch. After applying
these changes the issue disappeared.
Where is that patch? it didn't make it through to list - can you
just re-open 1457 and attach there?
Not I cannot due to I have no permissions for this.
Our patch looks like this:
Index: apr_thread_ext.c
===
--- apr_thread_ext.c (revision 449604)
+++ apr_thread_ext.c (working copy)
@@ -28,14 +28,14 @@
APR_DECLARE(apr_status_t) apr_thread_set_priority(apr_thread_t *thread,
apr_int32_t priority)
{
-HANDLE *os_thread;
+apr_os_thread_t * os_thread;
apr_status_t status;
-if (status = apr_os_thread_get(((apr_os_thread_t *)os_thread),
thread)) {
+if (status = apr_os_thread_get(os_thread, thread)) {
return status;
}
-if (SetThreadPriority(*os_thread, (int)convert_priority(priority))) {
+if (SetThreadPriority((HANDLE)os_thread,
(int)convert_priority(priority))) {
return APR_SUCCESS;
} else {
return apr_get_os_error();
@@ -50,23 +50,24 @@
// touch thread to flash memory
APR_DECLARE(apr_status_t) apr_thread_yield_other(apr_thread_t* thread) {
-HANDLE *os_thread = NULL;
+apr_os_thread_t * os_thread = NULL;
apr_status_t status;
-if (status = apr_os_thread_get(((apr_os_thread_t *)os_thread),
thread)) {
+if (status = apr_os_thread_get(os_thread, thread)) {
return status;
}
-if(!os_thread) {
-//printf (detached thread\n);
- return status;
-}
- //printf(suspending %d\n, *os_thread);
-if(-1!=SuspendThread(*os_thread)) {
- ResumeThread(*os_thread);
- // printf(resuming %d\n, *os_thread);
-} else {
- //printf(fail to suspend %d\n, *os_thread);
-}
- return APR_SUCCESS;
+if(!os_thread) {
+// printf (detached thread\n);
+return status;
+}
+
+// printf(suspending %d\n, *os_thread);
+if(SuspendThread((HANDLE)os_thread) != -1) {
+ResumeThread((HANDLE)os_thread);
+// printf(resuming %d\n, *os_thread);
+} else {
+// printf(fail to suspend %d\n, *os_thread);
+}
+return APR_SUCCESS;
}
APR_DECLARE(void) apr_memory_rw_barrier() {
@@ -79,19 +80,19 @@
FILETIME exitTime;
FILETIME kernelTime;
FILETIME userTime;
-HANDLE *hThread;
+apr_os_thread_t * os_thread;
SYSTEMTIME sysTime;
int res;
__int64 xx;
__int32 * pp;
apr_status_t status;
-if (status = apr_os_thread_get(((apr_os_thread_t *)hThread), thread))
{
+if (status = apr_os_thread_get(os_thread, thread)) {
return status;
}
res = GetThreadTimes(
-*hThread,
+(HANDLE)os_thread,
creationTime,
exitTime,
kernelTime,
@@ -125,13 +126,15 @@
APR_DECLARE(apr_status_t) apr_get_thread_time(apr_thread_t *thread,
apr_int64_t* nanos_ptr)
{
-HANDLE *os_thread;
+apr_os_thread_t * os_thread;
apr_status_t status;
FILETIME creation_time, exit_time, kernel_time, user_time;
-if (status = apr_os_thread_get(((apr_os_thread_t *)os_thread),
thread)!=APR_SUCCESS) {
+
+status = apr_os_thread_get(os_thread, thread);
+if (status != APR_SUCCESS) {
return status;
}
-GetThreadTimes(*os_thread, creation_time,
+GetThreadTimes((HANDLE)os_thread, creation_time,
exit_time, kernel_time,
user_time);
@@ -141,13 +144,15 @@
}
APR_DECLARE(apr_status_t) apr_thread_cancel(apr_thread_t *thread) {
-HANDLE *os_thread;
+apr_os_thread_t * os_thread;
apr_status_t status;
-if (status = apr_os_thread_get(((apr_os_thread_t *)os_thread),
thread)) {
+
+status = apr_os_thread_get(os_thread, thread);
+if (status != APR_SUCCESS) {
return status;
}
-if (TerminateThread(*os_thread, 0)) {
+if (TerminateThread((HANDLE)os_thread, 0)) {
return APR_SUCCESS;
} else {
return apr_get_os_error();
Thanks,
Vladimir.
Geir, could you please look at this patch and apply it if there are
no objections?
Thanks in advance,
Vladimir.
On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not
as worried - I went back a few days to r447025 and still
have the problem, so it's not from this morning. I guess this has
been masked all along by the logger problem. Noted in JIRA
Re: [drlvm][gc] HARMONY-1371 applied incompletely
Salikh, this change was reverted back, as it leads to crashes on some smoke tests. Look at the harmony-1371 comments. -- Ivan On 9/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Geir, Ivan, just a heads-up: the patch from HARMONY-1371 was applied incompletely. The below hunk was left out (i.e. it exists in HARMONY-1371, but was not committed to SVN). Is this okay? --- vm/gc/src/init.cpp +++ vm/gc/src/init.cpp @@ -51,7 +51,7 @@ int HEAP_SIZE_DEFAULT = 256 MB; unsigned int prev_mark_phase; bool cleaning_needed = false; -int gc_algorithm = 0; +int gc_algorithm = 30; int gc_adaptive = true; int64 timer_start; int64 timer_dt; -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. Thanks, Vladimir. Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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: [testing] HARMONY-995: adding new target to builds for automatic testing
On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: Seems, it will be convenient for automatic (or nightly) building and testing Harmony and, may be, newbie who want to look to what is Harmony today without documentation readingJ. If nobody objects I'll prepare patch. That's fine, I think, but I'm just surprised it doesn't do that now... what does it do now? Actually, now 3 targets should be called one-by-one (4 in case of vm) to reproduce development cycle. Of cause, external tool can do it but it is seems more reasonable to have this command in the build. Issue http://issues.apache.org/jira/browse/HARMONY-1565 with trivial update was created. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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: [drlvm] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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-1538) [classlib][awt] Successor of CubicCurve2D throws NPE in contains() if getBounds2D() returns null
Hi all
I think this is non-bug difference.
If successor of CubicCurve2D returns null instead of bounds then
Harmony throws NPE in contains() method while RI doesn't. It seems
like RI doesn't use getBounds2D() to implement contains() method while
Harmony does.
I see three possibilities
1. Exclude using of getBounds2D() from contains(). In this case
algorithm efficiency will slow down because it's part of optimization.
2. Add at contains() method an additional bounds calculation. In this
case we will get strange code duplication.
3. Stay as non-bug difference. It's very strange situation if shape
returns null bounds but such shapes are drawn well (run the test).
Comments?
2006/9/22, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] Successor of CubicCurve2D throws NPE in contains() if
getBounds2D() returns null
-
Key: HARMONY-1538
URL: http://issues.apache.org/jira/browse/HARMONY-1538
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Denis Kishenko
If successor of CubicCurve2D returns null instead of bounds then Harmony throws
NPE while RI doesn't. Harmony use shape bounds getBounds2D() to implement
contains() and intersects() methods but It seems like RI doesn't use bounds for
this.
== Test.java =
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.geom.*;
public class Test {
static public void main(String[] args) {
final CubicCurve2DImpl obj = new CubicCurve2DImpl(100, 100, 200, 200,
200, 100, 100, 200);
Frame f = new Frame(Test) {
public void paint(Graphics g) {
((Graphics2D)g).draw(obj);
}
};
f.setSize(600, 400);
f.show();
System.out.println(obj.contains=+obj.contains(0, 0));
}
}
class CubicCurve2DImpl extends java.awt.geom.CubicCurve2D.Double {
public CubicCurve2DImpl(double x1, double y1, double x2, double
y2, double x3, double y3, double x4, double y4) {
super(x1, y1, x2, y2, x3, y3, x4, y4);
}
public Rectangle2D getBounds2D() {
return null;
}
}
= RI Output =
obj.contains=false
Harmony output =
java.lang.NullPointerException
at org.apache.harmony.awt.gl.Crossing.crossShape(Crossing.java:506)
at java.awt.geom.CubicCurve2D.contains(CubicCurve2D.java:537)
--
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: [doc] new Getting Started guides
http://incubator.apache.org/harmony/quickhelp_contributors.html I have a couple of comments on the contents: 1. $ ant fetch-depends As I am sitting behind the firewall, I have to use $ ANT_OPTS='-Dhttp.proxyHost=proxy.host -Dhttp.proxyPort=proxy port' ant fetch-depends to make sure ant can download dependencies using HTTP proxy. 2. As of now, you cannot build from a Cygwin or other alternative shell. This is not exactly the case. - DRLVM has provisions in 'build.bat' to set up environment using Visual Studio environment file 'vsvars32.bat' (and friends). - if Visual Studio configured system environment during installation, then both DRLVM and Classlib can be built from any place. - 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] Trouble Building DRLVM
On the 0x1EC day of Apache Harmony Egor Pasko wrote: On the 0x1EB day of Apache Harmony Egor Pasko wrote: On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote: I modified the launcher to include both the vm directory as well as the launcher directory on the PATH/LD_LIBRARY_PATH. I am not catching .. the launcher directory is known without PATH/LD_LIBRARY_PATH. Why should we look at PATH? Can those that have been having troubles with shared lib loading give it a try, and report back, and please mention the platform you are running on... SUSE 9: * HelloWorld works without complaining, cool! * JAVA_HOME crash is gone, great! (but are we not ignoring JAVA_HOME yet?) * tests: * ThreadTest failed on JET (looks like a known issue:) * ~4 tests failed on OPT (ThreadTest too), I'll look at them I picked the ClassLoaderTest. It passes on JET and failes on OPT. Looks like it is time to open a JIRA... If nobody objects, :) I'll put some words here as an example how to investigate JIT compiler problems. I hope, it might be useful for people. I ran it as a single test like this: .../jre/bin/java -Xem:opt -Xbootclasspath/a:$HARMONY/working_classlib/depends/jars/junit_3.8.2/junit.jar:$HARMONY/working_vm/build/lnx_ia32_gcc_debug/semis/kernel.tests/classes junit.textui.TestRunner java.lang.ClassLoaderTest If invoked with the option -Xtrace:em, DRLVM prints compilation events as soon as they occur. What makes real fun is that one method starts compilation several times (without success) and receives SEGFAULT after not so many attempts. The bug may be in OPT or in recompilation, not clear now. Will investigate (first, I'll try to compile some methods with JET selectively) the bug is caused by OPT's incorrect compilation of method test_getPackages_V if I move the compilation to JET, the test passes. Investigating... Moving compilation of _one_ method to JET, while _others_ are compiled with OPT *is easy*. All you have to do is put debug.emconf file to .../jre/bin/default and run with the option -Xem:debug debug.emconf is as follows: chains=chain1,chain2 chain1.jits=JET_DEBUG chain2.jits=CD_OPT chain1.filter=+::test_getPackages_V chain1.filter=- JET_DEBUG.file=jitrino CD_OPT.file=jitrino # Options to be passed to JIT -Djit.JET_DEBUG.path= -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method -Djit.CD_OPT.path.dce1=cg_dce -Djit.CD_OPT.path.dce2=cg_dce -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc #inliner configuration -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline -Djit.CD_OPT.arg.codegen.dce1.early=yes -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM -- 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]
[drlvm][launcher] performance issue when loading property (was Re: [launcher] Patch is available for harmonyvm.properties parsing)
Alexey, would you create JIRA for this? Looks you have more information about the problem? -- Ivan On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Please... On Sep 23, 2006, at 7:58 AM, Alexey Varlamov wrote: Ha! This is apr_file_gets() who does this! So this is DRLVM specific and duplicates classlib's efforts. We should get rid of this. 2006/9/23, Ivan Volosyuk [EMAIL PROTECTED]: You are right. It is different property file: $JRE/lib/boot/bootclasspath.properties (6kbyte) The strace looks like following. Not quite effective. The number of syscalls is greater then all others at the startup of VM. I would like to file a performance JIRA for the issue, but I don't quite understand if it DRLVM specific or classlib? -- Ivan read(3, #, 1) = 1 read(3, , 1) = 1 read(3, C, 1) = 1 read(3, o, 1) = 1 read(3, p, 1) = 1 read(3, y, 1) = 1 read(3, r, 1) = 1 read(3, i, 1) = 1 read(3, g, 1) = 1 read(3, h, 1) = 1 read(3, t, 1) = 1 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (HARMONY-1569) [drlvm][testing] JAVA_HOME veriable should be set to tested runtime before test run
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
Re: [classlib][awt] Fonts with negative size.
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
I agree, that the behavior of the negative-sized fonts on RI is looks like
the behavior of positive ones with -Pi rotation. However, if we look at the
font metrics, bounds - we can see negative values for height, width
values...I'm not sure they have any sence without additional documentation
that we can't find in the spec.
Moreover bug evaluation says that RI handles negative-sized fonts for
components in different ways depending on the platform. And it's behavior
unlike the drawing on the frame surface. What is to add - metrics for all
these various cases are the same, it means that RI has erroneous behavior in
some way.
I would suggest not to follow the RI and mark it as non-bug difference as
the RI hasn't any clear documentation on this problem and it's
behavior erroneous and depends on the platform or component type.
Thanks,
Ilya.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size
can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(,
new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks
quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543
,w=-5.46875
,h=- 5.7495117]
Actually, I dont see any sence in negative height and width
metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen,
you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to
choose only
positive sized fonts. Also I've looked on the GDI LOGFONT
structure
description in MSDN and I've seen there again that we deal with
absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
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]
-
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [jira] Created: (HARMONY-1570) [classlibl][awt] RI considers that negative rectangle is contained inside empty GeneralPath
Hi all
I have found strange behaviour of RI implementation of
java.awt.geom.GeneralPath.
RI returns TRUE for following code while Harmony returns FALSE
new GeneralPath().contains(0, 0, -10, -10))
Actually TRUE result is absolutely illogical because of
1. GeneralPath is empty
2. Negative width and height meen that rectangle is empty too
I have marked this issue as non-bug difference.
Any comments?
2006/9/25, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlibl][awt] RI considers that negative rectangle is contained inside empty
GeneralPath
---
Key: HARMONY-1570
URL: http://issues.apache.org/jira/browse/HARMONY-1570
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of GeneralPath.contains(x, y, width, height) returns true if
input width and height are negative and GeneralPath is empty. It's absolutely
illogical.
=== Test.java ===
import junit.framework.TestCase;
import junit.textui.TestRunner;
import java.awt.geom.GeneralPath;
public class Test extends TestCase {
public void testcase0() {
GeneralPath p = new GeneralPath();
assertTrue(p.contains(0, 0, -10, -10));
}
static public void main(String[] args) {
TestRunner.run(Test.class);
}
}
= RI ===.
Time: 0,031
OK (1 test)
=== Harmony ===
Time: 0.328
There was 1 failure:
1) testcase0(Test)junit.framework.AssertionFailedError
at Test.testcase0(Test.java:10)
at java.lang.reflect.VMReflection.invokeMethod()
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
*/
--
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: [classlib][awt] Fonts with negative size.
It seems like returning negative metrics is somewhat logical. If the
font is rotated by -Pi then all offsets becomes negative, but their
absolute values are equal to the positive ones.
I'll try to give an example. E.g. if descent was, say, 10 and one
needed to offset 10 pt from the origin (baseline) to the bottom of the
black box then if -pi rotation is applied to the font, one need to
offset -10 pt from the baseline since black box is upside down.
Yes, RI failed to be consistent with this on heavyweight components as
it was noted in the evaluation. But is this bug still there in the RI?
And if RI is inconsistent with the drawing of negative-sized fonts it
is still consistent with the negative metrics, right?
IMHO, the ideal behavior in all situations would be the following:
If the font has negative size we assume that it has all the same
metrics as the positive font, but the metrics which has a direction
(like ascent, descent, etc.) are with the different sign. The font is
drawn as it was rotated by -pi angle.
Personaly my opinion is that this is a bug, not non-bug diff.
I'd suggest to choose between these options:
1. Fix metrics and rendering, close this issue.
2. Fix metrics, open a new jira for the rendering of the negative-sized fonts.
3. Fix nothing, open a new jira or add an evaluation to this one
both for the rendering and for the metrics. This means that we want to
have them together.
For the rendering part, why not just add a transform if the size of
the font is negative?
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
I agree, that the behavior of the negative-sized fonts on RI is looks like
the behavior of positive ones with -Pi rotation. However, if we look at the
font metrics, bounds - we can see negative values for height, width
values...I'm not sure they have any sence without additional documentation
that we can't find in the spec.
Moreover bug evaluation says that RI handles negative-sized fonts for
components in different ways depending on the platform. And it's behavior
unlike the drawing on the frame surface. What is to add - metrics for all
these various cases are the same, it means that RI has erroneous behavior in
some way.
I would suggest not to follow the RI and mark it as non-bug difference as
the RI hasn't any clear documentation on this problem and it's
behavior erroneous and depends on the platform or component type.
Thanks,
Ilya.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size
can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(,
new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks
quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543
,w=-5.46875
,h=- 5.7495117]
Actually, I dont see any sence in negative height and width
metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen,
you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to
choose only
positive sized fonts. Also I've looked on the GDI LOGFONT
structure
description in MSDN and I've seen there again that we deal with
absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because
Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
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
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Alexey, There numerous sources. [1] is jar file specification - look for Class-Path attribute description, [2] is from Java tutorials series - read through first paragraph. I'm sure that more direct statement can be found at java.sun.com. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html [2] http://java.sun.com/docs/books/tutorial/ext/basics/load.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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: [drlvm] my latest round of patches broke something
Geir, Vladimir, I've returned from vacation today, so my 2 cents to this discussion... I guess the problem have appeared because in r449399 the changes for win/apr_thread_ext.c were committed, but new file patches/win/APR/threadproc/win32/thread.c was not committed. These changes are work together. The patch suggested by Vladimir will not fix issue completely. I cannot provide a test for issue I have fixed (I can't understand how to create it), but it's quite enough to uncomment debug printing in apr_thread_yield_other() function to view differences on any simple Java application. 2006/9/25, Vladimir Gorr [EMAIL PROTECTED]: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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][apr] APR fails to load a JIT library when using a fully qualified path
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. On 9/22/06, Mikhail Fursov [EMAIL PROTECTED] wrote: APR gurus! I have a question I can't answer by myself. Usually to develop and test new JIT features I use custom EM configuration file to move problem methods to a separate JIT instance. Now I can't use this feature, because APR is unable to load a JIT library with a fully specied path. So the problem is: 1) I ask EM to use custom JIT library: C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll 2) EM asks VM (APR) to load this module 3) In dso.c, line 77 I see that 'wpath' variable is valid, but LoadLibraryExW is failed. The error message is : Failure to open JIT dll file://C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll720126 I know that there is nothing wrong with my DLL because if I copy it to the default jitrino.dll location and do not use any paths everything works fine. The simplest way to reproduce the bug is to use -Dem.jitPath= path to jitrino.dll option. Once path to jitrino.dll is just 'jitrino.dll' APR loads DLL, but if you change it to the full path to the same dll, APR fails to load it. ? -- Mikhail Fursov -- Mikhail Fursov
Re: [classlib][awt] Fonts with negative size.
Guys, I found something in the Java 6.0 documentation.
If you look at the TextAttribute spec there is a note for the SIZE
field, attribute key for the font size:
Attribute key for the font size. Values are instances of *Number*. The
default value is 12pt.
This corresponds to the size parameter to the Font constructor.
Very large or small sizes will impact rendering performance, and the
rendering system might not render text at these sizes. *Negative sizes are
illegal and result in the default size*.
For this reason I suggest to use default size (12pt) if font has negative
size parameter. Any thoughts?
I believe negative-sized fonts support was erroneous in Java 5.0 and
in the earlier versions of Java.
Regards,
Ilya.
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It seems like returning negative metrics is somewhat logical. If the
font is rotated by -Pi then all offsets becomes negative, but their
absolute values are equal to the positive ones.
I'll try to give an example. E.g. if descent was, say, 10 and one
needed to offset 10 pt from the origin (baseline) to the bottom of the
black box then if -pi rotation is applied to the font, one need to
offset -10 pt from the baseline since black box is upside down.
Yes, RI failed to be consistent with this on heavyweight components as
it was noted in the evaluation. But is this bug still there in the RI?
And if RI is inconsistent with the drawing of negative-sized fonts it
is still consistent with the negative metrics, right?
IMHO, the ideal behavior in all situations would be the following:
If the font has negative size we assume that it has all the same
metrics as the positive font, but the metrics which has a direction
(like ascent, descent, etc.) are with the different sign. The font is
drawn as it was rotated by -pi angle.
Personaly my opinion is that this is a bug, not non-bug diff.
I'd suggest to choose between these options:
1. Fix metrics and rendering, close this issue.
2. Fix metrics, open a new jira for the rendering of the negative-sized
fonts.
3. Fix nothing, open a new jira or add an evaluation to this one
both for the rendering and for the metrics. This means that we want to
have them together.
For the rendering part, why not just add a transform if the size of
the font is negative?
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
I agree, that the behavior of the negative-sized fonts on RI is looks
like
the behavior of positive ones with -Pi rotation. However, if we look at
the
font metrics, bounds - we can see negative values for height, width
values...I'm not sure they have any sence without additional
documentation
that we can't find in the spec.
Moreover bug evaluation says that RI handles negative-sized fonts for
components in different ways depending on the platform. And it's
behavior
unlike the drawing on the frame surface. What is to add - metrics for
all
these various cases are the same, it means that RI has erroneous
behavior in
some way.
I would suggest not to follow the RI and mark it as non-bug difference
as
the RI hasn't any clear documentation on this problem and it's
behavior erroneous and depends on the platform or component type.
Thanks,
Ilya.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there
is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative
size
can be
created on RI.
Unfortunately spec keep silence about fonts with negative
sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = +
localFont.getLineMetrics(,
new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
I've worked with it, nice tool! +1 On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: +1 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] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib][awt] Fonts with negative size.
+1 I also think that it is better to follow 6.0 spec in this situation and to suggest that all the words said about TextAttribute are applicable to the Font itself. Actually, using default font size is definitely more reasonable behavior then playing with those negative values and the only concern was compatibility. But if 6.0 spec goes this way then, I think, we must do the same. Still there's a question what would be the metrics for the explicitely transformed font? On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote: Guys, I found something in the Java 6.0 documentation. If you look at the TextAttribute spec there is a note for the SIZE field, attribute key for the font size: Attribute key for the font size. Values are instances of *Number*. The default value is 12pt. This corresponds to the size parameter to the Font constructor. Very large or small sizes will impact rendering performance, and the rendering system might not render text at these sizes. *Negative sizes are illegal and result in the default size*. For this reason I suggest to use default size (12pt) if font has negative size parameter. Any thoughts? I believe negative-sized fonts support was erroneous in Java 5.0 and in the earlier versions of Java. Regards, Ilya. On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: It seems like returning negative metrics is somewhat logical. If the font is rotated by -Pi then all offsets becomes negative, but their absolute values are equal to the positive ones. I'll try to give an example. E.g. if descent was, say, 10 and one needed to offset 10 pt from the origin (baseline) to the bottom of the black box then if -pi rotation is applied to the font, one need to offset -10 pt from the baseline since black box is upside down. Yes, RI failed to be consistent with this on heavyweight components as it was noted in the evaluation. But is this bug still there in the RI? And if RI is inconsistent with the drawing of negative-sized fonts it is still consistent with the negative metrics, right? IMHO, the ideal behavior in all situations would be the following: If the font has negative size we assume that it has all the same metrics as the positive font, but the metrics which has a direction (like ascent, descent, etc.) are with the different sign. The font is drawn as it was rotated by -pi angle. Personaly my opinion is that this is a bug, not non-bug diff. I'd suggest to choose between these options: 1. Fix metrics and rendering, close this issue. 2. Fix metrics, open a new jira for the rendering of the negative-sized fonts. 3. Fix nothing, open a new jira or add an evaluation to this one both for the rendering and for the metrics. This means that we want to have them together. For the rendering part, why not just add a transform if the size of the font is negative? On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: It was evaluated as not a bug. But it is clear from its evaluation that negative-sized fonts are treated as positive sized but rotated around their origin, say with implicit transform. I'd suggest to follow this behavior. I agree, that the behavior of the negative-sized fonts on RI is looks like the behavior of positive ones with -Pi rotation. However, if we look at the font metrics, bounds - we can see negative values for height, width values...I'm not sure they have any sence without additional documentation that we can't find in the spec. Moreover bug evaluation says that RI handles negative-sized fonts for components in different ways depending on the platform. And it's behavior unlike the drawing on the frame surface. What is to add - metrics for all these various cases are the same, it means that RI has erroneous behavior in some way. I would suggest not to follow the RI and mark it as non-bug difference as the RI hasn't any clear documentation on this problem and it's behavior erroneous and depends on the platform or component type. Thanks, Ilya. On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Google said this is the bug of RI in progress [1]. However there is no distinct resolution yet... It's reported again Java 1.1.8 more than 3 years agao. I don't think RI will fix this bug. Richard. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 2006/9/23, Richard Liang [EMAIL PROTECTED]: On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote: Hi, all! I was playing with fonts and found that Font with negative size can be created on RI. Unfortunately spec keep silence about fonts with negative sizes. On Harmony if font size is negative then it is set to zero. test.java--- import java.awt.*; import
Re: [drlvm] my latest round of patches broke something
The hang on gc.LOS on windows has been present for at least one week. I broke into the hung DRLVM with microsoft debugger. Its running jitted code that loops. The loop seems to involve synchronization primitives (see email chain [drlvm] gc.LOS hangs on win32) I still suspect a bug that is somehow associated with Object.wait(). Its interesting to note what recently changed that might have an impact: - new thread manager - launcher was integrated The launcher starts out in the context of classlib's portlib . The classlib portlib context is later on partially replaced with PORTLIB, a C struct where all the members are nulled out. Apparently signals run in the context of classlib's portlib and the new thread manager runs in its own (appropriate) context. In any case, both classlib portlib and the new threading manager have implementations of monitor_wait(). There may some conflict on when and where each version of monitor wait is called. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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] -- Weldon Washburn Intel Middleware Products Division
Re: [jira] Created: (HARMONY-1538) [classlib][awt] Successor of CubicCurve2D throws NPE in contains() if getBounds2D() returns null
On 9/25/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
I think this is non-bug difference.
If successor of CubicCurve2D returns null instead of bounds then
Harmony throws NPE in contains() method while RI doesn't. It seems
like RI doesn't use getBounds2D() to implement contains() method while
Harmony does.
I see three possibilities
1. Exclude using of getBounds2D() from contains(). In this case
algorithm efficiency will slow down because it's part of optimization.
2. Add at contains() method an additional bounds calculation. In this
case we will get strange code duplication.
3. Stay as non-bug difference. It's very strange situation if shape
returns null bounds but such shapes are drawn well (run the test).
Comments?
To follow RI I would suggest to add check (if the bounds2D is null) to the
contains() method, in this case just to return false.
Regards, Ilya.
2006/9/22, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] Successor of CubicCurve2D throws NPE in contains() if
getBounds2D() returns null
-
Key: HARMONY-1538
URL: http://issues.apache.org/jira/browse/HARMONY-1538
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Denis Kishenko
If successor of CubicCurve2D returns null instead of bounds then Harmony
throws NPE while RI doesn't. Harmony use shape bounds getBounds2D() to
implement contains() and intersects() methods but It seems like RI doesn't
use bounds for this.
== Test.java =
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.geom.*;
public class Test {
static public void main(String[] args) {
final CubicCurve2DImpl obj = new CubicCurve2DImpl(100, 100,
200, 200, 200, 100, 100, 200);
Frame f = new Frame(Test) {
public void paint(Graphics g) {
((Graphics2D)g).draw(obj);
}
};
f.setSize(600, 400);
f.show();
System.out.println(obj.contains=+obj.contains(0, 0));
}
}
class CubicCurve2DImpl extends java.awt.geom.CubicCurve2D.Double {
public CubicCurve2DImpl(double x1, double y1, double x2,
double y2, double x3, double y3, double x4, double y4) {
super(x1, y1, x2, y2, x3, y3, x4, y4);
}
public Rectangle2D getBounds2D() {
return null;
}
}
= RI Output =
obj.contains=false
Harmony output =
java.lang.NullPointerException
at org.apache.harmony.awt.gl.Crossing.crossShape(Crossing.java:506)
at java.awt.geom.CubicCurve2D.contains(CubicCurve2D.java:537)
--
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]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [drlvm][jit] possible ABCD bug
Hello Egor, I'm glad to hear the bug is real. It is a sign that I have learned how the ABCD code works. As you pointed out, this was no easy feat! :-) I wanted to do exactly what you seem to have already started. The fact that the existing ABCD pass does not build an inequality graph was very surprising to me. The pass tries to use SSA use-def chains as a substitute, which they certainly are not. The reason is subtle, but it has very severe implications on the effectiveness of the pass. It is sad, because this decision is central to the algorithm and means that much of the existing ABCD code is not useful to work with. I would definitely like to improve jitrino's ABCD, and would be happy to help you in your efforts. Thanks, Naveen On Sep 25, 2006, at 2:11 AM, Egor Pasko wrote: On the 0x1EE day of Apache Harmony Naveen Neelakantam wrote: I've been reading through the ABCD implementation in jitrino, and if I understand it correctly, I found a bug. I've attached a patch to fix it. Someone who actually understands the code should verify this. Naveen, you found a secret :) Recently, I spent some time understanding Jitrino's ABCD code too. Now it seems pretty clear, you pinpointed a bug. I did not try the patch on a strong benchmark such as DaCapo, and cannot estimate how much it can give in terms of performance. (Although, it is both a performance and correctness related fix) As you pointed out recently, checking both bounds assumes one comparison in CG. So, we won't get any performance benefit on IA-32 if we remove only one (lower or upper) bound of a 'chkbounds'. Also, did anyone ever test this ABCD pass? That's a long story. And here is the secret: Jitrino ABCD removes *only* lower bounds checks. Thus, it is useless currently. Well, this is not 100% true :) Sometimes, I saw it removing upper checks, but, probably, very obvious checks. I should have looked into the problem more thoroughly. This is a very sad story, so I decided to look what is happening. The algorithm is *not* easy to read, but what I can say for sure: * it is not the algorithm as in the original paper * it's algorithm applies some more advanced techniques (i.e. analysis of bounds of the kind A*x+B, where A and B are constants, x is a variable) and lacks them * inequality graph is not built, thus uncovering some extra limitations * the algorithm assumes all constants to be zero, when proving a check to eliminate. So, I cannot find any evidence for the algorithm to remove an upper check :( I tried the original ABCD example from the paper. And was upset almost like you :) I tried to trigger various switches, but they gave no clue, except a lot of assertions out of the blue. I ask because I've tried running it on a bidirectional bubble sort as mentioned in the original paper. The paper mentions that the pass should be able to prove all of the bounds checks in the sort method as redundant/ unnecessary. However, when I try running the abcd pass on a bidirectional bubble sort (attached), none of the bounds checks are eliminated. well, some actually are: bash$ grep We can eliminate naveen.sort.log We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau !!! We can eliminate LB check of I43:chkbounds g195.16 .lt. g8.8 -) g25:tau We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau !!! We can eliminate LB check of I54:chkbounds g32 .lt. g8.18 -) g36:tau We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau !!! We can eliminate LB check of I64:chkbounds g180 .lt. g8.8 -) g45:tau We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau !!! We can eliminate LB check of I74:chkbounds g194 .lt. g8.12 -) g55:tau We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau !!! We can eliminate LB check of I118:chkbounds g82.27 .lt. g8.1 -) g92:tau We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau !!! We can eliminate LB check of I129:chkbounds g80.31 .lt. g8.32 -) g103:tau We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau !!! We can eliminate LB check of I314:chkbounds g196 .lt. g8.5 -) g199:tau We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau !!! We can eliminate LB check of I294:chkbounds g218.3 .lt. g8.1 -) g185:tau but, you see, only lower bounds! (BTW, I applied your fix, it had no influence on your specific test) ...The code was so buggy and not easy to read, so I decided to implement the original algorithm by myself :) Well, I implemented the algorithm on a given inequality graph. Tested it a bit, and became satisfied on how it works. Now I am working on the IR-to-InequalityGraph transformer. And almost implemented it. At this point there is not a lot to do there to make the code working and eliminating. But, hey, you are the first to talk about ABCD on this list! I am so glad, someone found it too. If you are
[drlvm] Please integrate HARMONY -1340.
Committers, Could you please integrate fix from: HARMONY -1340 Fix invalid assertion in thread_native_fat_monitor.c The patch is trivial. The assertion in the current code is incorrect, it check that monitor is entered not more then once (recursion_count 1) It was left in the code by mistake. The monitor recursion count could be any positive number (the number of nested monitorEnter calls). This assert happend quite often: in self hosting mode, and always on EM64T. Thanks Artem - 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] invoking non-trivial jars results in IllegalAccessError
Pavel, Thanks for the links - I found smth interesting in the last one. Note, however: all of them mention that the application or extension class loader should use the Class-Path attribute, not arbitrary URLClassLoader. Moreover, this depends on the context - e.g. the extension CL should ignore it. And the URLClassLoader does not provide any API to control this. Though our URLClassLoader is aware of the Class-Path attribute and current JarRunner impl works, we may need to revisit this issue in sometime... -- Regards, Alexey 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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] - 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] my latest round of patches broke something
Folks, You may find interesting investigations in HARMONY-1519 [1] of bugs in patched APR condition variables on Win32, which affect wait() behavior. [1]http://issues.apache.org/jira/browse/HARMONY-1519?page=all 2006/9/25, Weldon Washburn [EMAIL PROTECTED]: The hang on gc.LOS on windows has been present for at least one week. I broke into the hung DRLVM with microsoft debugger. Its running jitted code that loops. The loop seems to involve synchronization primitives (see email chain [drlvm] gc.LOS hangs on win32) I still suspect a bug that is somehow associated with Object.wait(). Its interesting to note what recently changed that might have an impact: - new thread manager - launcher was integrated The launcher starts out in the context of classlib's portlib . The classlib portlib context is later on partially replaced with PORTLIB, a C struct where all the members are nulled out. Apparently signals run in the context of classlib's portlib and the new thread manager runs in its own (appropriate) context. In any case, both classlib portlib and the new threading manager have implementations of monitor_wait(). There may some conflict on when and where each version of monitor wait is called. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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] -- 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: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
2006/9/25, Mikhail Fursov [EMAIL PROTECTED]: 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. It would be really nice, projects are convenient for browsing/editing native sources on Windows. OTOH using them for compilation may be a concern, just like the one above - someone have to keep them in sync with common build system. But I suppose you are not alone in the way you work with MSVC anyway - so let's try. +1 from me. -- Alexey On 9/22/06, Mikhail Fursov [EMAIL PROTECTED] wrote: APR gurus! I have a question I can't answer by myself. Usually to develop and test new JIT features I use custom EM configuration file to move problem methods to a separate JIT instance. Now I can't use this feature, because APR is unable to load a JIT library with a fully specied path. So the problem is: 1) I ask EM to use custom JIT library: C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll 2) EM asks VM (APR) to load this module 3) In dso.c, line 77 I see that 'wpath' variable is valid, but LoadLibraryExW is failed. The error message is : Failure to open JIT dll file://C:/users/mfursov/harmony_trace2/drlvm/trunk/vm/jitrino/bin/debug/jitrino.dll720126 I know that there is nothing wrong with my DLL because if I copy it to the default jitrino.dll location and do not use any paths everything works fine. The simplest way to reproduce the bug is to use -Dem.jitPath= path to jitrino.dll option. Once path to jitrino.dll is just 'jitrino.dll' APR loads DLL, but if you change it to the full path to the same dll, APR fails to load it. ? -- Mikhail Fursov -- Mikhail Fursov - 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] my latest round of patches broke something
I looked at it( gc.LOS hang ) for a while and my findings are somewhat similar to Alexey's. The problem occurs for me all the time irrespective of where the trace statement apprears( ref: Weldon's comment ). On breaking in, the call stack at hang is: ntdll.dll!7c90eb94() ntdll.dll!7c90ea53() kernel32.dll!7c81e956() hythr.dll!apr_winapi_SwitchToThread() Line 219 + 0x2b C hythr.dll!apr_thread_yield() Line 195 C hythr.dll!hythread_yield() Line 297 C hythr.dll!wait_safe_region_event(HyThread * thread=0x0e80d408) Line 227 C hythr.dll!hythread_suspend_all(HyThread * * t=0x036af7b0, HyThreadGroup * group=0x) Line 401 + 0x9 C harmonyvm.dll!stop_the_world_root_set_enumeration() Line 89 + 0xb C++ harmonyvm.dll!vm_enumerate_root_set_all_threads() Line 143 C++ gc.dll!enumerate_universe() Line 127 + 0x8 C++ gc.dll!copy_gc(int size=4108) Line 326 + 0x16 C++ gc.dll!select_gc(int size=4108) Line 96 + 0x9 C++ gc.dll!gc_alloc(unsigned int in_size=4108, unsigned int ah=21234656, void * thread_pointer=0x0102c4cc) Line 238 + 0x9 C++ harmonyvm.dll!vm_new_vector_using_vtable_and_thread_pointer(int length=4096, unsigned int vector_handle=21234656, void * tp=0x0102c4cc) Line 233 + 0x14 C++ harmonyvm.dll!vm_rt_new_vector_using_vtable_and_thread_pointer(int length=4096, unsigned int vector_handle=21234656, void * tp=0x0102c4cc) Line 111 + 0x11 C++ 01341775() harmonyvm.dll!set_unwindable(bool unwindable=true) Line 140 + 0xd C++ ntdll.dll!7c90e591() ntdll.dll!7c90110a() hythr.dll!apr_thread_mutex_unlock(apr_thread_mutex_t * mutex=0x014ddba6) Line 117 C gc.dll!GC_VTable_Info::is_finalizible() Line 121 + 0x16 C++ 207ea704() jitrino.dll!Jitrino::Jet::rt_h_i64_a(__int64 v1=502568517412, __int64 v2=0, JavaByteCodes op=OPCODE_NOP) Line 211 + 0x2f C++ ntdll.dll!7c9106eb() ntdll.dll!7c9011a7() ntdll.dll!7c96cde9() ntdll.dll!7c918e94() ntdll.dll!7c918f87() ntdll.dll!7c90e591() ntdll.dll!7c926abe() ntdll.dll!7c96cde9() ntdll.dll!7c96e0f0() ntdll.dll!7c96e0d4() ntdll.dll!7c918dfa() ntdll.dll!7c90d625() harmonyvm.dll!initialize_arg_list_iterator(const char * descr=0x0057c530) Line 52 + 0x7 C++ harmonyvm.dll!Method::get_argument_list() Line 237 + 0x11 C++ 036afd5c() harmonyvm.dll!JIT_execute_method_default(void * jit=0x, _jmethodID * methodID=0x02686c40, jvalue * return_value=0x, jvalue * args=0x036afeac) Line 199 C++ em.dll!DrlEMImpl::executeMethod(_jmethodID * meth=0x02686c40, jvalue * return_value=0x, jvalue * args=0x036afeac) Line 488 + 0x16 C++ em.dll!ExecuteMethod(_jmethodID * meth=0x02686c40, jvalue * return_value=0x, jvalue * args=0x036afeac) Line 42 + 0x21 C++ harmonyvm.dll!vm_execute_java_method_array(_jmethodID * method=0x02686c40, jvalue * result=0x, jvalue * args=0x036afeac) Line 58 + 0x1c C++ harmonyvm.dll!call_method_no_ref_result(JNIEnv_External * env=0x0084e958, _jobject * obj=0x02d7e1a0, _jmethodID * methodID=0x02686c40, jvalue * args=0x, jvalue * result=0x, int non_virtual=0) Line 164 + 0x11 C++ harmonyvm.dll!CallVoidMethodA(JNIEnv_External * env=0x0084e958, _jobject * obj=0x02d7e1a0, _jmethodID * methodID=0x02686c40, jvalue * args=0x) Line 199 + 0x19 C++ harmonyvm.dll!wrapper_proc(void * arg=0x02d74078) Line 98 + 0x27 C hythr.dll!thread_start_proc(apr_thread_t * thd=0x0042c180, void * p_args=0x0042c0d8) Line 704 + 0xf C hythr.dll!dummy_worker(void * opaque=0x0042c180) Line 79 + 0x13 C hythr.dll!_threadstartex(void * ptd=0x0039f3a8) Line 241 + 0xd C kernel32.dll!7c80b50b() gc.dll!Partial_Reveal_Object::obj_info() Line 148 + 0x3d C++ kernel32.dll!7c8399f3() There seems to be some kind of endless loop in apr_winapi_switchtothread() ,and I suspect that the problem may be quite similar to Alexey's findings. I plan to investigate, but at this moment I am too broken with several tests failing before I can even get to this point. Thanks, Rana On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Folks, You may find interesting investigations in HARMONY-1519 [1] of bugs in patched APR condition variables on Win32, which affect wait() behavior. [1]http://issues.apache.org/jira/browse/HARMONY-1519?page=all
Re: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
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: [EMAIL PROTECTED]
Re: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
Ok, I will create a new JIRA issue tomorrow (or even today, it's 2am here:) ) and add MSVC projects for some DRLVM components. On 9/26/06, Gregory Shimansky [EMAIL PROTECTED] 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: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [drlvm][apr] APR fails to load a JIT library when using a fully qualified path
On Monday 25 September 2006 22:38 Mikhail Fursov wrote: Ok, I will create a new JIRA issue tomorrow (or even today, it's 2am here:) ) and add MSVC projects for some DRLVM components. BTW absence of up to date VS.NET projects for VM is one of the reasons I don't use it for development :) Another one is that VS.NET 2003 sometimes goes into infinite loop in the source editor. This is not the case with VS.NET 2005, it also has a better debugger, but building with it is not possible ATM due to lots of changes introduced by Microsoft in 8.0. They should be fixed some day. On 9/26/06, Gregory Shimansky [EMAIL PROTECTED] 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. -- 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] my latest round of patches broke something
On 9/25/06, Ilya Berezhniuk [EMAIL PROTECTED] wrote: Geir, Vladimir, I've returned from vacation today, so my 2 cents to this discussion... I guess the problem have appeared because in r449399 the changes for win/apr_thread_ext.c were committed, but new file patches/win/APR/threadproc/win32/thread.c was not committed. These changes are work together. The patch suggested by Vladimir will not fix issue completely. Maybe you are right. However I'd advise not to ignore our changes. In our opinion they are also useful. I see this patch eliminates a lot of test failures we have now on Windows. BTW Rana mentions about this as well. Thanks, Vladimir. I cannot provide a test for issue I have fixed (I can't understand how to create it), but it's quite enough to uncomment debug printing in apr_thread_yield_other() function to view differences on any simple Java application. 2006/9/25, Vladimir Gorr [EMAIL PROTECTED]: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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] my latest round of patches broke something
Hi Weldon/Geir, Looks like we have quite a few Windows failures. Could one of you folks please add in the the new file: patches/win/APR/threadproc/win32/thread.c that is in 1457, but possibly got dropped from the commit? We also need H-1340 to fix the assert in the fat monitor. H-1519 may be needed ( I suspect it is ), but we can look at it after the first two fixes have gone in? Thanks, Rana On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Ilya Berezhniuk [EMAIL PROTECTED] wrote: Geir, Vladimir, I've returned from vacation today, so my 2 cents to this discussion... I guess the problem have appeared because in r449399 the changes for win/apr_thread_ext.c were committed, but new file patches/win/APR/threadproc/win32/thread.c was not committed. These changes are work together. The patch suggested by Vladimir will not fix issue completely. Maybe you are right. However I'd advise not to ignore our changes. In our opinion they are also useful. I see this patch eliminates a lot of test failures we have now on Windows. BTW Rana mentions about this as well. Thanks, Vladimir. I cannot provide a test for issue I have fixed (I can't understand how to create it), but it's quite enough to uncomment debug printing in apr_thread_yield_other() function to view differences on any simple Java application. 2006/9/25, Vladimir Gorr [EMAIL PROTECTED] : On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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] my latest round of patches broke something
Vladimir Gorr wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Right - that patch was only for windows too. On WinXP, MSVC .NET 2003 geir Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
Vladimir Gorr wrote: On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok 2) the problem was because JAVA_HOME was pointing to the RI 3) we should ignore the patch you inlined in the message before this one geir Thanks, Vladimir. Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [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: [doc] new Getting Started guides
Salikh Zakirov wrote: http://incubator.apache.org/harmony/quickhelp_contributors.html I have a couple of comments on the contents: 1. $ ant fetch-depends As I am sitting behind the firewall, I have to use $ ANT_OPTS='-Dhttp.proxyHost=proxy.host -Dhttp.proxyPort=proxy port' ant fetch-depends to make sure ant can download dependencies using HTTP proxy. Excellent point. We'll add that. 2. As of now, you cannot build from a Cygwin or other alternative shell. This is not exactly the case. - DRLVM has provisions in 'build.bat' to set up environment using Visual Studio environment file 'vsvars32.bat' (and friends). - if Visual Studio configured system environment during installation, then both DRLVM and Classlib can be built from any place. Have you built classlib successfully with cygwin? - 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] Trouble Building DRLVM
Egor Pasko wrote: If invoked with the option -Xtrace:em, DRLVM prints compilation events as soon as they occur. What makes real fun is that one method starts compilation several times (without success) and receives SEGFAULT after not so many attempts. The bug may be in OPT or in recompilation, not clear now. Will investigate (first, I'll try to compile some methods with JET selectively) the bug is caused by OPT's incorrect compilation of method test_getPackages_V if I move the compilation to JET, the test passes. Investigating... Moving compilation of _one_ method to JET, while _others_ are compiled with OPT *is easy*. All you have to do is put debug.emconf file to .../jre/bin/default and run with the option -Xem:debug This is *really* cool. (Of course, I assume a patch is forthcoming to fix OPT :) We should capture this in a FAQ... geir debug.emconf is as follows: chains=chain1,chain2 chain1.jits=JET_DEBUG chain2.jits=CD_OPT chain1.filter=+::test_getPackages_V chain1.filter=- JET_DEBUG.file=jitrino CD_OPT.file=jitrino # Options to be passed to JIT -Djit.JET_DEBUG.path= -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method -Djit.CD_OPT.path.dce1=cg_dce -Djit.CD_OPT.path.dce2=cg_dce -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc #inliner configuration -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline -Djit.CD_OPT.arg.codegen.dce1.early=yes -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM - 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] invoking non-trivial jars results in IllegalAccessError
We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- 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: [drlvm] Trouble Building DRLVM
On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=HDK path/bin/:HDK path/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. -- 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] Trouble Building DRLVM
I have been trying to follow this thread as best as possible. I apologize if this has already been addressed. Does anyone else have the problem of the executable just hanging? I know some people had this problem before, but I wasn't sure what the fix ended up being (if there was one). Here is the problem I am seeing: When I run ./java it runs fine (after I comment out the assertion on line 183 of thread_native_fat_monitor.c). 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 (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=HDK path/bin/:HDK path/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. - 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][html] Differences with RI
Miguel Montes wrote: Hi, I fllled several JIRA issues more than three weeks ago, but they are still unassigned. (HARMONY-1272, 1349, 1350, 1395). We are working in the parser, and there are some issues that should be solved, such as the structure of ContentModel. I'd like to look at patches for 1349 and 1350 today, but 1395 is a contribution, so probably it needs Geir to raise a voting on it. And anyone interests to provide a patch for 1272? I would like to hear other people thoughts about this, particularly those from the developers of the existing javax.swing.text.html.parser code Regards Miguel Montes On 8/23/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I think that filing JIRA issue is right way :) 2006/8/23, Miguel Montes [EMAIL PROTECTED]: Hi: We have found several differences between Harmony's implementation of j.s.t.h.parser and the RI. I'm not sure if these should be reported individually as JIRA issues, or should be discussed here. For instance, in j.s.t.h.p.Entity, the RI. encodes isParameter and isGeneral in the type, which is a public field, while the current implementation in Harmony uses two boolean fields. So, the value of a public field is different in both implementations. Another case: ContentModel: The method first() should return the element that must be the first element to appear in a ContentModel. If it's not unique, the RI returns null. For instance, for the following ContentModel: TITLE ISINDEX? BASE? Any of those elements could appear at the beggining of a valid matching expression. So, the method first should return null, because there is not a single element that could be considered as the unique one that can appear at the head of a matching expression. Nevertheless, for this example (as for some others), HARMONY-948 returned a value. For this example, a BASE value was obtained. There are several more. Should we post them as separate JIRA issues, o as one big issue, with the suggeste patches? -- Miguel Montes -- 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] -- 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]
please, integrate issues 1565 and 1569
Committers, please, integrate issues 1565 and 1569. These improvements are trivial but important for 'BT infrastructure'. Thanks, Vladimir
Re: [classlib][awt] Fonts with negative size.
Agree. We may follow Java 6.0 Spec.
Richard.
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Guys, I found something in the Java 6.0 documentation.
If you look at the TextAttribute spec there is a note for the SIZE
field, attribute key for the font size:
Attribute key for the font size. Values are instances of *Number*. The
default value is 12pt.
This corresponds to the size parameter to the Font constructor.
Very large or small sizes will impact rendering performance, and the
rendering system might not render text at these sizes. *Negative sizes are
illegal and result in the default size*.
For this reason I suggest to use default size (12pt) if font has negative
size parameter. Any thoughts?
I believe negative-sized fonts support was erroneous in Java 5.0 and
in the earlier versions of Java.
Regards,
Ilya.
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It seems like returning negative metrics is somewhat logical. If the
font is rotated by -Pi then all offsets becomes negative, but their
absolute values are equal to the positive ones.
I'll try to give an example. E.g. if descent was, say, 10 and one
needed to offset 10 pt from the origin (baseline) to the bottom of the
black box then if -pi rotation is applied to the font, one need to
offset -10 pt from the baseline since black box is upside down.
Yes, RI failed to be consistent with this on heavyweight components as
it was noted in the evaluation. But is this bug still there in the RI?
And if RI is inconsistent with the drawing of negative-sized fonts it
is still consistent with the negative metrics, right?
IMHO, the ideal behavior in all situations would be the following:
If the font has negative size we assume that it has all the same
metrics as the positive font, but the metrics which has a direction
(like ascent, descent, etc.) are with the different sign. The font is
drawn as it was rotated by -pi angle.
Personaly my opinion is that this is a bug, not non-bug diff.
I'd suggest to choose between these options:
1. Fix metrics and rendering, close this issue.
2. Fix metrics, open a new jira for the rendering of the negative-sized
fonts.
3. Fix nothing, open a new jira or add an evaluation to this one
both for the rendering and for the metrics. This means that we want to
have them together.
For the rendering part, why not just add a transform if the size of
the font is negative?
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
I agree, that the behavior of the negative-sized fonts on RI is looks
like
the behavior of positive ones with -Pi rotation. However, if we look at
the
font metrics, bounds - we can see negative values for height, width
values...I'm not sure they have any sence without additional
documentation
that we can't find in the spec.
Moreover bug evaluation says that RI handles negative-sized fonts for
components in different ways depending on the platform. And it's
behavior
unlike the drawing on the frame surface. What is to add - metrics for
all
these various cases are the same, it means that RI has erroneous
behavior in
some way.
I would suggest not to follow the RI and mark it as non-bug difference
as
the RI hasn't any clear documentation on this problem and it's
behavior erroneous and depends on the platform or component type.
Thanks,
Ilya.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there
is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative
size
can be
created on RI.
Unfortunately spec keep silence about fonts with negative
sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = +
localFont.getLineMetrics(,
new
FontRenderContext(null, false,
Re: [drlvm] Trouble Building DRLVM
On the 0x1F0 day of Apache Harmony 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 (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=HDK path/bin/:HDK path/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. Thanks, Gregory! I saw Ivan's resolution and appreciate his work. Tried that yesterday, and it worked. Great! I think we should document this since it is going to stay for a long time and is really required for development on Linux. +1 (!!) we need to document this. BTW, I have my own collection of GDB tricks that could be useful when debugging. Some of them significantly help me from time to time. I would like to contribute them to Harmony. I would suggest to make a special HOWTO or Getting Started for DRLVM's Linux debugging. It might seem too specific, but we have a lot to tell here, and, IMHO, this is a strong reason to make a separate doc. How to document? My ideas: * start from Wiki, when it matures, move to the website * make a JIRA with a patch introducing a new, text-only documentation file, like README * start JIRA with exact patch to the website (probably, it is not the easiest way, though, Nadya has a HOWTO for that) Any suggestions? -- 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] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok Geir, any simple application fails for me on Windows as well. It seems we really miss patches/win/APR/threadproc/win32/thread.c. Could you put it in? 2) the problem was because JAVA_HOME was pointing to the RI I believe when Vladimir was talking about JAVA_HOME it was related to ActiveMQ application only. Evgueni 3) we should ignore the patch you inlined in the message before this one geir Thanks, Vladimir. Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [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] my latest round of patches broke something
On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok What about *patches/win/APR/threadproc/win32/thread.c* file? 2) the problem was because JAVA_HOME was pointing to the RI Absolutely. 3) we should ignore the patch you inlined in the message before this one I'm not sure. This patch eliminates a lot of test failures as I mentioned before (BTW you also commented on same issue into H-1457). Do we want to live with this? And one more note is our patch is not related with eliminating the ActiveMQ crash. It's another story. Thanks, Vladimir. geir Thanks, Vladimir. Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [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] Please integrate HARMONY -1340.
Done On Sep 25, 2006, at 12:40 PM, Artem Aliev wrote: Committers, Could you please integrate fix from: HARMONY -1340 Fix invalid assertion in thread_native_fat_monitor.c The patch is trivial. The assertion in the current code is incorrect, it check that monitor is entered not more then once (recursion_count 1) It was left in the code by mistake. The monitor recursion count could be any positive number (the number of nested monitorEnter calls). This assert happend quite often: in self hosting mode, and always on EM64T. Thanks Artem - 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] my latest round of patches broke something
On Sep 25, 2006, at 5:07 PM, Rana Dasgupta wrote: Hi Weldon/Geir, Looks like we have quite a few Windows failures. Could one of you folks please add in the the new file: patches/win/APR/threadproc/win32/thread.c that is in 1457, but possibly got dropped from the commit? Possibly? Most definitely! So sorry. I was a bonehead. We also need H-1340 to fix the assert in the fat monitor. Done H-1519 may be needed ( I suspect it is ), but we can look at it after the first two fixes have gone in? Look away Thanks, Rana On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Ilya Berezhniuk [EMAIL PROTECTED] wrote: Geir, Vladimir, I've returned from vacation today, so my 2 cents to this discussion... I guess the problem have appeared because in r449399 the changes for win/apr_thread_ext.c were committed, but new file patches/win/APR/threadproc/win32/ thread.c was not committed. These changes are work together. The patch suggested by Vladimir will not fix issue completely. Maybe you are right. However I'd advise not to ignore our changes. In our opinion they are also useful. I see this patch eliminates a lot of test failures we have now on Windows. BTW Rana mentions about this as well. Thanks, Vladimir. I cannot provide a test for issue I have fixed (I can't understand how to create it), but it's quite enough to uncomment debug printing in apr_thread_yield_other() function to view differences on any simple Java application. 2006/9/25, Vladimir Gorr [EMAIL PROTECTED] : On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. It certainly did on my machine after a clean - update build, and then hung on gc.LOS. Under what platform? This problem exists only for Windows. Thanks, Vladimir. The detailed investigation showed the patch for H-1457 is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Where is that patch? it didn't make it through to list - can you just re-open 1457 and attach there? Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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] - 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: harmony-dev- [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] my latest round of patches broke something
On Sep 26, 2006, at 12:25 AM, Vladimir Gorr wrote: On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Under what platfrom, what build? On Windows for build I've built from the latest sources (at 449592 revision). Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore all works. So just to make this perfectly clear : 1) the code in SVN is ok What about *patches/win/APR/threadproc/win32/thread.c* file? Done 2) the problem was because JAVA_HOME was pointing to the RI Absolutely. 3) we should ignore the patch you inlined in the message before this one I'm not sure. This patch eliminates a lot of test failures as I mentioned before (BTW you also commented on same issue into H-1457). Do we want to live with this? And one more note is our patch is not related with eliminating the ActiveMQ crash. It's another story. I wasn't arguing, I was trying to figure out what you were saying, because it seemed like once you did a clean rebuild, all was ok. Now I'll assume that all was *not* ok. I just added thread.c. My fault - I overlooked it. Sorry. Thanks, Vladimir. geir Thanks, Vladimir. Thanks, Vladimir. On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote: BTW I've forgot to say ActiveMQ 4.0 works w/o any problems. Thanks, Vladimir. On 9/25/06, Vladimir Gorr [EMAIL PROTECTED] wrote: As for me (and other people) a lot of tests fail for the latest sources (revision 449592). I've run the *build.bat clean; build.bat update; build.bat* command in compliance with comments for *H-1457*. It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this. The detailed investigation showed the patch for *H-1457* is incorrect. I've attached a patch fixing this issue. Thanks Evgueni Brevnov for preparing this patch. After applying these changes the issue disappeared. Geir, could you please look at this patch and apply it if there are no objections? Thanks in advance, Vladimir. On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c- unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [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] Trouble Building DRLVM
submit a FAQ patch to JIRA under website. Just put a question and answer in the body of the JIRA, and we'll do the rest. geir On Sep 25, 2006, at 7:27 PM, 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 (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=HDK path/bin/:HDK path/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. -- 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] Trouble Building DRLVM
On Sep 25, 2006, at 11:16 PM, Egor Pasko wrote: On the 0x1F0 day of Apache Harmony 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 (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=HDK path/bin/:HDK path/bin/ default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. Thanks, Gregory! I saw Ivan's resolution and appreciate his work. Tried that yesterday, and it worked. Great! I think we should document this since it is going to stay for a long time and is really required for development on Linux. +1 (!!) we need to document this. BTW, I have my own collection of GDB tricks that could be useful when debugging. Some of them significantly help me from time to time. I would like to contribute them to Harmony. I would suggest to make a special HOWTO or Getting Started for DRLVM's Linux debugging. It might seem too specific, but we have a lot to tell here, and, IMHO, this is a strong reason to make a separate doc. How to document? My ideas: * start from Wiki, when it matures, move to the website * make a JIRA with a patch introducing a new, text-only documentation file, like README * start JIRA with exact patch to the website (probably, it is not the easiest way, though, Nadya has a HOWTO for that) Any suggestions? JIRAs or Wiki - either one so we can capture and put on website. It think that FAQs are useful for this - we can organize by topic... -- 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] - 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 25, 2006, at 6:49 AM, Vladimir Ivanov wrote: On 9/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 5:05 AM, Vladimir Ivanov wrote: Seems, it will be convenient for automatic (or nightly) building and testing Harmony and, may be, newbie who want to look to what is Harmony today without documentation readingJ. If nobody objects I'll prepare patch. That's fine, I think, but I'm just surprised it doesn't do that now... what does it do now? Actually, now 3 targets should be called one-by-one (4 in case of vm) to reproduce development cycle. Of cause, external tool can do it but it is seems more reasonable to have this command in the build. I see what you mean. I don't agree. The nice thing about having the external tool, is that the external tool can report on which phase broke. By calling an ubertarget that does everything, all it knows is that the ubertarget failed. For example, if you know that the tests failed, the system could examine the svn log between the time that the tests passed, and the time they failed, and send a note to developers giving them a hint of what changed to help find out what went wrong. If sophisticated enough, it could just figure it out from stack trace, and mail the responsible developer directly :) 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: [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: [doc] new Getting Started guides
Geir, At http://incubator.apache.org/harmony/quickhelp_users.html, There is a download page link to, http://incubator.apache.org/harmony/download.html which should be, http://incubator.apache.org/harmony/downloads.html -Jordan On 9/21/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]
