Re: [drlvm] my latest round of patches broke something
On 9/26/06, Dmitry Durnev [EMAIL PROTECTED] wrote: On 9/26/06, Vladimir Gorr [EMAIL PROTECTED] wrote: [...] 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. For me nothing works under windows (on latest drlvm/debug build) without this patch. Even Hello, world fails(after printing Hello world!) with SEH handler: shutdown error and shows 2 debug messegaboxes(1 is from the launcher). And this happens irrespective of my JAVA_HOME setting, I tried both to unset it, and to point to Harmony JRE... Debugging shows that in apr_thread_ext.c in apr_thread_set_priority() SetThreadPriority(*os_thread,...) call fails with access violation... So I think your patch, Vladimir, is useful :) Dmitry, did you run 'build.bat clean' before starting the build process? Maybe a clue for your issue is here. At least I have same issue right now. Thanks, Vladimir. -- Dmitry A. Durnev, 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/26/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/26/06, Dmitry Durnev [EMAIL PROTECTED] wrote: On 9/26/06, Vladimir Gorr [EMAIL PROTECTED] wrote: [...] 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. For me nothing works under windows (on latest drlvm/debug build) without this patch. Even Hello, world fails(after printing Hello world!) with SEH handler: shutdown error and shows 2 debug messegaboxes(1 is from the launcher). And this happens irrespective of my JAVA_HOME setting, I tried both to unset it, and to point to Harmony JRE... Debugging shows that in apr_thread_ext.c in apr_thread_set_priority() SetThreadPriority(*os_thread,...) call fails with access violation... So I think your patch, Vladimir, is useful :) Dmitry, did you run 'build.bat clean' before starting the build process? I meant *build.bat update*, certainly. In this case all works fine w/o my patch, I'd like to slightly continue the discussion about this patch. No needs to apply it now after Geir committed the thread.c file for *H-1457*. This file contains a fix for the APR bug. (BTW it'd be not bad to mention about this issue on the APR dev list. Sure it makes sense). Our patch is a workaround to avoid this bug. Thanks, Vladimir. Maybe a clue for your issue is here. At least I have same issue right now. Thanks, Vladimir. -- Dmitry A. Durnev, 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
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: [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: [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] 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] 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] 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: [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
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: [doc] new Getting Started guides
On 9/22/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Both are good. And much better then commercial one. :) Vladimir, It's license is not very important for us since we do not plan to include it in Harmony. We just suggest a tool to user. yes, you're right. Thanks, Vladimir. SY, Alexey 2006/9/22, Robin Garner [EMAIL PROTECTED]: Robin Garner wrote: Vladimir Gorr wrote: On 9/22/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Since Harmony is an open source project probably we should change the link from commercial WinZip to open source 7-Zip[1] :) It has *GNU LGPL. *IIRC we can't use this, can it? Thanks, Vladimir. Isn't info-zip the standard free distribution ? It has an essentially public domain license afaict. Correction: BSD-style. SY, Alexey 1. http://www.7-zip.org/ 2006/9/22, Geir Magnusson Jr. [EMAIL PROTECTED]: 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] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On 22 Sep 2006 17:31:41 +0700, Egor Pasko [EMAIL PROTECTED] 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 strangest piece of the trace looks like this (funny, huh?) EM: compile done:[CS_OPT n=919: OK] java/lang/Object::wait()V EM: compile start:[CS_OPT n=921] java/io/FileOutputStream::finalize()V EM: compile start:[CS_OPT n=922] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V EM: compile start:[CS_OPT n=923] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V EM: compile start:[CS_OPT n=924] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V EM: compile start:[CS_OPT n=925] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V EM: compile start:[CS_OPT n=926] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V EM: compile start:[CS_OPT n=927] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V EM: compile start:[CS_OPT n=928] java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V SIGSEGV in VM code. EM: compile done:[CS_OPT n=920: OK] java/nio/channels/spi/AbstractInterruptibleChannel::close()V EM: compile start:[CS_OPT n=929] org/apache/harmony/nio/internal/FileChannelImpl::implCloseChannel()V Stack trace: 1: ?? (??:-1) end of stack trace Segmentation fault with -Xno_parallel_jit option (re)compilation order should be somewhat different, and here it is: EM: compile done:[CS_OPT n=915: OK] java/util/zip/ZipFile::finalize()V EM: compile start:[CS_OPT n=917] java/util/zip/ZipFile::close()V EM: compile done:[CS_OPT n=916: OK] java/lang/Object::wait()V EM: compile start:[CS_OPT n=918] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=919] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=920] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=921] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=922] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=923] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=924] java/util/zip/ZipFile::close()V EM: compile start:[CS_OPT n=925] java/util/zip/ZipFile::close()V SIGSEGV in VM code. Stack trace: 1: ?? (??:-1) end of stack trace what makes me really nervous is that I cannot debug in GDB on Linux (!) Why not to reproduce this situation on Windows and not to use the MVS debugger? IIRC this problem also exists for Windows. Thanks, Vladimir. 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? -- 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] NPE is thrown when the kernel tests are run on Windows at revision 448448
On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle.init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
On 9/21/06, Elena Semukhina [EMAIL PROTECTED] wrote: Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, Is it possible to give more details about this or to file new JIRA issue? Thanks, Vladimir. but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- 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] -- Thanks, Elena
Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen 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] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
On 9/22/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) I meant you need to slightly *wait *some time here. Thanks, Vladimir. - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty ( UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace ( UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen 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] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
On 9/22/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. I've revert the update for HARMONY-1500 at revision r448784, please check if the problem disappears. Yep, it helps and helped as I mentioned yet yesterday. One thing I don't understand is why this problem exists only on Windows. I mean all works fine w/o any changes for Linux. Can anybody explain me this? Thanks, Vladimir. Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen 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] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] getting activeMQ to run
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Even though we have the jar issue fixed w/t he launcher-based build, I still can't run ActiveMQ using release build on Ubuntu. Can anyone else report success? Or a patch? :) I was succesfull on Windows. No success exist for Linux however. Steps I do are the following: 1. unset JAVA_HOME 2. set PATH=.../jre/bin;PATH 3. cd .../activemq-3.2.3\bin; activemq Are these steps correct? Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:32 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 21, 2006, at 11:23 PM, Vladimir Gorr wrote: On 9/22/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. I've revert the update for HARMONY-1500 at revision r448784, please check if the problem disappears. Yep, it helps and helped as I mentioned yet yesterday. One thing I don't understand is why this problem exists only on Windows. I mean all works fine w/o any changes for Linux. Can anybody explain me this? I saw a problem on Linux that went away when it was rolled back... It's very strange I don't see this problem on my side. I'm working on SUSE whereas you use Ubiuntu. Maybe a clue is here? Dunno. My tests worked. It showed up when I tried to run Eclipse. It has now gone away, and is showing me another bug when I run Eclipse. Yep, I'm aware about this. Thanks. But I'm too tired to do it now... bedtime... Good night! Thanks, Vladimir. geir Thanks, Vladimir. geir Thanks, Vladimir. Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType (UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace (UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java: 3091) [junit] at java.lang.Character.isWhitespace(Character.java: 3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen China Software Development Lab, IBM - 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] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] Running build test (on linux)
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Hi All,
I have some kind of configuration problem. DRLVM's 'build test' fails
on my machine on kernel tests with attached message. As I can see
junit.jar is added in CLASSPATH in build.sh script, but something not
work as expected. '-Djuint.home=make/tmp' or
'-Djunit.jar=make/tmp/junit.jar' doesn't help either. What is the
hidden knowledge how to run the tests?
Try to indicate an absolute path to the jar file. I want to hope all should
work for this case.
Please, let know me if it helps.
Thanks,
Vladimir.
--
Ivan
--- build.sh test output ---
kernel.test:
-run-kernel-test:
[echo]
[echo] ==
[echo] Run kernel tests using jitrino.jet
[echo] ==
[echo]
[mkdir] Created dir:
/home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/kernel.tests/reports/jitrino.jet
[echo] RUNNING : java.lang.Class1_5Test
BUILD FAILED
/home/ivan/svn/drlvm/trunk/build/make/build.xml:373: The following
error occurred while executing this line:
/home/ivan/svn/drlvm/trunk/build/make/build_component.xml:72: The
following error occurred while executing this line:
/home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/build/targets/kernel.test.xml:149:
The following error occurred while executing this line:
/home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/build/targets/kernel.test.xml:161:
Could not create task or type of type: junit.
Ant could not find the task or a class this task relies upon.
This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
- You have misspelt 'junit'.
Fix: check your spelling.
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
- The task is an Ant optional task and the JAR file and/or libraries
implementing the functionality were not found at the time you
yourself built your installation of Ant from the Ant sources.
Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
task and make sure it contains more than merely a
META-INF/MANIFEST.MF.
If all it contains is the manifest, then rebuild Ant with the needed
libraries present in ${ant.home}/lib/optional/ , or alternatively,
download a pre-built release version from apache.org
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
- The task is not an Ant core or optional task
and needs to be declared using taskdef.
- You are attempting to use a task defined using
presetdef or macrodef but have spelt wrong or not
defined it at the point of use
Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath
Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.
-
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] none of kernel tests passed for the recent sources
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 19, 2006, at 7:19 AM, Vladimir Gorr wrote: On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: guys - lets be clear. Are you unsetting it because it was pointing to Sun or BEA or IBM, or was it set to harmony? as for me JAVA_HOME refers to JRockit. have you tried setting it to harmony? yes, I did but w/o success: ... Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK ... I wanted to say I tried to run our tests (build.sh test) with this setting. If we need to set JAVA_HOME to the .../deploy/jre how we're going to get around this. Yes - I understand. I assume you can run the tests if you unset? We need to figure out why it's suddenly affecting us, with all the recent changes. I'm assuming it's something I did, as I changed how resources are loaded.. I've understood a reason of the test failures when the kernel tests are run via this command: ./build.bat kernel.test *An incorrect message is displayed for this case* [echo] == [echo] Please set the classpath of junit as follows: [echo] build.bat -Djunit.jar=%JUNIT_HOME% test [echo] == *Indeed it should look like* [echo] == [echo] Please set the classpath of junit as follows: [echo] build.bat -Djunit.*home*=%JUNIT_HOME% test [echo] == *In this case all works just fine.* Thanks, Vladimir. geir Thanks, Vladimir. Thanks, Vladimir. geir On Sep 19, 2006, at 7:01 AM, Egor Pasko wrote: I got almost the same recently. try 'unset JAVA_HOME' On the 0x1E9 day of Apache Harmony Dmitry Durnev wrote: I observe vm crash with the similar stack trace on my SUSE Linux box, when trying to launch Hello World app on debug version of DRLVM: *** glibc detected *** free(): invalid pointer: 0xbfffbde8 *** SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (??:-1) 5: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/ natives_support.cpp:117) 6: properties_free (??:-1) 7: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/ natives_support.cpp:117) 8: ?? (??:-1) 9: readClassPathFromPropertiesFile (??:-1) 10: ?? (??:-1) 11: ?? (??:-1) 12: ?? (??:-1) 13: ?? (??:-1) 14: ?? (??:-1) 15: _dl_runtime_resolve (??:-1) 16: ?? (??:-1) 17: JNI_OnLoad (??:-1) 18: ?? (??:-1) end of stack trace On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis \kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel tests now on Ubuntu 6, release build, and they are running fine. What platform? debug version on Windows platforms. I have no success on SUSE LINUX as well: ... -run-kernel-test-batch: [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build
Re: [DRLVM] Running build test (on linux)
On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Hi All,
I have some kind of configuration problem. DRLVM's 'build test' fails
on my machine on kernel tests with attached message. As I can see
junit.jar is added in CLASSPATH in build.sh script, but something not
work as expected. '-Djuint.home=make/tmp' or
'-Djunit.jar=make/tmp/junit.jar' doesn't help either. What is the
hidden knowledge how to run the tests?
Try to indicate an absolute path to the jar file. I want to hope all
should work for this case.
Please, let know me if it helps.
Unfortunately, I cannot run the testing on Linux due to the well-known
issue:
...
[echo] ==
[echo] Run kernel tests using jitrino.jet
[echo] ==
[echo]
[mkdir] Created dir:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/kernel.tests/reports/jitrino.jet
[echo] RUNNING : java.lang.Class1_5Test
[junit] java/lang/UnsatisfiedLinkError : Failed loading library
libhyzlib.so: DSO load failed
[junit] Test java.lang.Class1_5Test FAILED
[echo] RUNNING : java.lang.Class5Test
[junit] java/lang/UnsatisfiedLinkError : Failed loading library
libhyzlib.so: DSO load failed
...
Thanks,
Vladimir.
--
Ivan
--- build.sh test output ---
kernel.test :
-run-kernel-test:
[echo]
[echo] ==
[echo] Run kernel tests using jitrino.jet
[echo] ==
[echo]
[mkdir] Created dir:
/home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/kernel.tests/reports/jitrino.jet
[echo] RUNNING : java.lang.Class1_5Test
BUILD FAILED
/home/ivan/svn/drlvm/trunk/build/make/build.xml:373: The following
error occurred while executing this line:
/home/ivan/svn/drlvm/trunk/build/make/build_component.xml:72: The
following error occurred while executing this line:
/home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/build/targets/kernel.test.xml:149:
The following error occurred while executing this line:
/home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/build/targets/kernel.test.xml:161:
Could not create task or type of type: junit.
Ant could not find the task or a class this task relies upon.
This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
- You have misspelt 'junit'.
Fix: check your spelling.
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
- The task is an Ant optional task and the JAR file and/or libraries
implementing the functionality were not found at the time you
yourself built your installation of Ant from the Ant sources.
Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
task and make sure it contains more than merely a
META-INF/MANIFEST.MF.
If all it contains is the manifest, then rebuild Ant with the needed
libraries present in ${ant.home}/lib/optional/ , or alternatively,
download a pre-built release version from apache.org
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
- The task is not an Ant core or optional task
and needs to be declared using taskdef.
- You are attempting to use a task defined using
presetdef or macrodef but have spelt wrong or not
defined it at the point of use
Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath
Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]build failed on windows
On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: fixed. please verify. Yes, this issue disappeared. Thanks, Vladimir. And apologies... geir On Sep 20, 2006, at 10:07 PM, Geir Magnusson Jr. wrote: Sorry. My fault. Fixing now. I need to find settings to make gcc on linux enforce the same... geir On Sep 20, 2006, at 9:36 PM, Leo Li wrote: Hi, all I found that the classlib build fails on windows today. I have tried to fixed it in File main.c 1. move some declarations of variables to the top part of a function. at line 311: char *dirs[2]; at line 1045: int found = 0; int i=0; at line 1067:int strLen 2. comments out unused variable at line 1019: //UDATA newPathLength; -- Leo Li 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] - 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] Running build test (on linux)
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Thank you, looks like I had incomplete installation of ant. It finally works for me, a few tests fails though, some of them on RI according to messages. Is it expected behaviour? Not. All our tests should be passed for DRLVM (due to our VM has no some bugs RI has). RI runs when DRLVM fails (just to make sure). If some tests fails it means we need to understand why. I don't like we have a lot of failures for Jitrino.OPT. Probably not all patches depend on H-1363 have been applied or some new issue appeared. We need to investigate this in any case. You can workaround your problem, copy all libraries from jre/bin into jre/bin/default. This is quick and dirty solution. I guess no needs to make this. All works at 448426 revision. Thanks, Vladimir. -- Ivan On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Hi All, I have some kind of configuration problem. DRLVM's 'build test' fails on my machine on kernel tests with attached message. As I can see junit.jar is added in CLASSPATH in build.sh script, but something not work as expected. '-Djuint.home=make/tmp' or '-Djunit.jar=make/tmp/junit.jar' doesn't help either. What is the hidden knowledge how to run the tests? Try to indicate an absolute path to the jar file. I want to hope all should work for this case. Please, let know me if it helps. Unfortunately, I cannot run the testing on Linux due to the well-known issue: ... [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/kernel.tests/reports/jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed [junit] Test java.lang.Class1_5Test FAILED [echo] RUNNING : java.lang.Class5Test [junit] java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed ... Thanks, Vladimir. -- 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] none of kernel tests passed for the recent sources
On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So all is well? Yep if not to take into account some test failures. Thanks, Vladimir. On Sep 20, 2006, at 8:55 AM, Vladimir Gorr wrote: On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 19, 2006, at 7:19 AM, Vladimir Gorr wrote: On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: guys - lets be clear. Are you unsetting it because it was pointing to Sun or BEA or IBM, or was it set to harmony? as for me JAVA_HOME refers to JRockit. have you tried setting it to harmony? yes, I did but w/o success: ... Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK ... I wanted to say I tried to run our tests (build.sh test) with this setting. If we need to set JAVA_HOME to the .../deploy/jre how we're going to get around this. Yes - I understand. I assume you can run the tests if you unset? We need to figure out why it's suddenly affecting us, with all the recent changes. I'm assuming it's something I did, as I changed how resources are loaded.. I've understood a reason of the test failures when the kernel tests are run via this command: ./build.bat kernel.test *An incorrect message is displayed for this case* [echo] == [echo] Please set the classpath of junit as follows: [echo] build.bat -Djunit.jar=%JUNIT_HOME% test [echo] == *Indeed it should look like* [echo] == [echo] Please set the classpath of junit as follows: [echo] build.bat -Djunit.*home*=%JUNIT_HOME% test [echo] == *In this case all works just fine.* Thanks, Vladimir. geir Thanks, Vladimir. Thanks, Vladimir. geir On Sep 19, 2006, at 7:01 AM, Egor Pasko wrote: I got almost the same recently. try 'unset JAVA_HOME' On the 0x1E9 day of Apache Harmony Dmitry Durnev wrote: I observe vm crash with the similar stack trace on my SUSE Linux box, when trying to launch Hello World app on debug version of DRLVM: *** glibc detected *** free(): invalid pointer: 0xbfffbde8 *** SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (??:-1) 5: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/ natives_support.cpp:117) 6: properties_free (??:-1) 7: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/ natives_support.cpp:117) 8: ?? (??:-1) 9: readClassPathFromPropertiesFile (??:-1) 10: ?? (??:-1) 11: ?? (??:-1) 12: ?? (??:-1) 13: ?? (??:-1) 14: ?? (??:-1) 15: _dl_runtime_resolve (??:-1) 16: ?? (??:-1) 17: JNI_OnLoad (??:-1) 18: ?? (??:-1) end of stack trace On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis \kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel
Re: [DRLVM] Running build test (on linux)
On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 20, 2006, at 10:44 PM, Vladimir Gorr wrote: On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Thank you, looks like I had incomplete installation of ant. It finally works for me, a few tests fails though, some of them on RI according to messages. Is it expected behaviour? Not. All our tests should be passed for DRLVM (due to our VM has no some bugs RI has). RI runs when DRLVM fails (just to make sure). If some tests fails it means we need to understand why. I don't like we have a lot of failures for Jitrino.OPT. Probably not all patches depend on H-1363 have been applied or some new issue appeared. We need to investigate this in any case. You can workaround your problem, copy all libraries from jre/bin into jre/bin/default. This is quick and dirty solution. I guess no needs to make this. All works at 448426 revision. I assume that has my recent fix to the launcher? I don't doubt. Can you tellme what OS you are using, and can others verify as well? (and report their OS too...) Sorry I didn't let you know before: [EMAIL PROTECTED]:~ cat /etc/issue Welcome to SUSE LINUX Enterprise Server 9 (i586) - Kernel \r (\l). Thanks, Vladimir. geir Thanks, Vladimir. -- Ivan On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Hi All, I have some kind of configuration problem. DRLVM's 'build test' fails on my machine on kernel tests with attached message. As I can see junit.jar is added in CLASSPATH in build.sh script, but something not work as expected. '-Djuint.home=make/tmp' or '-Djunit.jar=make/tmp/junit.jar' doesn't help either. What is the hidden knowledge how to run the tests? Try to indicate an absolute path to the jar file. I want to hope all should work for this case. Please, let know me if it helps. Unfortunately, I cannot run the testing on Linux due to the well- known issue: ... [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/ lnx_ia32_gcc_debug/semis/kernel.tests/reports/jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed [junit] Test java.lang.Class1_5Test FAILED [echo] RUNNING : java.lang.Class5Test [junit] java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed ... Thanks, Vladimir. -- 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: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle.init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. Thanks, Vladimir.
Re: [DRLVM] Build problems - missing bfd.h
Probably, not all packages have been installed on your machine. As for me it's very strange you've struck against this problem. Some time ago a patch has been prepared eliminating this dependency. Geir, could you please comment on this? Or did I miss anything again? Thanks in advance, Vladimir. On 9/21/06, Robin Garner [EMAIL PROTECTED] wrote: Trying to build the latest trunk (r448461) on Ubuntu (6.06). Had to hack build.sh because the ant executable isn't in ANT_HOME, and add a URL to download xalan, but now the build fails with a missing bfd.h (full error message below). Any pointers ? cheers, Robin -- build.native.c: [cc] Starting dependency analysis for 10 files. [cc] 10 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 2 total files to be compiled. [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:21:17: error: bfd.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:22:21: error: dis-asm.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:63: error: syntax error before 'fprintf_ftype' [cc] cc1: warnings being treated as errors [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: 'struct disassemble_info' declared inside parameter list [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: its scope is only this definition or declaration, which is probably not what you want [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:70: error: field 'bfd_info' has incomplete type [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: error: syntax error before 'bfd_decoder' [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: initialization makes integer from pointer without a cast [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: data definition has no type or storage class [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:89: error: syntax error before 'src' [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function 'disasm_read_memory': [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: 'buffer' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: (Each undeclared identifier is reported only once [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: for each function it appears in.) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: 'src' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: 'n' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: At top level: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:103: error: syntax error before 'memaddr' [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function 'disasm_print_adress_default': [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: 'info' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: 'memaddr' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function 'disasm_print': [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:177: error: 'bfd_vma' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:177: error: syntax error before 'apr_uint32_t' [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:183: error: syntax error before 'apr_uint32_t' [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function 'port_disasm_initialize': [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:297: error: 'disassembler_ftype' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:297: error: syntax error before 'bfd_print_insn_sym' [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function 'port_disassembler_create': [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:330: error: 'bfd_arch_i386' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:331: error: 'bfd_mach_i386_i386_intel_syntax' undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:339: error: 'BFD_ENDIAN_LITTLE' undeclared (first use in this function) BUILD FAILED
Re: [drlvm] HARMONY-1363 - status update
On 9/19/06, Chris Gray [EMAIL PROTECTED] wrote: On Monday 18 September 2006 18:14, Geir Magnusson Jr. wrote: Pavel Pervov wrote: Tried it on Windows and found the problem which, as it looks like, have never been caught before. As I discovered, launcher uses platform specific line separators to parse harmonyvm.properties on a specific platform. But haromynvm.properties, which is copied into deploy, has unix line endings and is skipped. As the result, EM can't initialize.' A ha! I workarounded this by running unix2dos on harmonyvm.properties. Ok - we should get that in as eol-native Wouldn't it be better (and safer) to fix the parser? +1. Indeed this is the good thing for doing to avoid the above-mentioned problem in future. Thanks, Vladimir. Normally a properties file can contain any kind of line separators and still be parsed correctly, which is a Good Thing IMHO. E.g. according to the spec for java.util.Properties.load(), A natural line of input is terminated either by a set of line terminator characters (\n or \r or \r\n) or by the end of the file. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] none of kernel tests passed for the recent sources
Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis\kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Thanks in advance, Vladimir.
Re: [drlvm] none of kernel tests passed for the recent sources
On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis\kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel tests now on Ubuntu 6, release build, and they are running fine. What platform? debug version on Windows platforms. I have no success on SUSE LINUX as well: ... -run-kernel-test-batch: [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/kernel.tests/reports/batch.mode [junit] Running org.apache.harmony.lang.generics.ClassLoaderTest [junit] SIGSEGV in VM code. [junit] Stack trace: [junit] 1: properties_free (??:-1) [junit] 2: ?? (??:-1) [junit] 3: readClassPathFromPropertiesFile (??:-1) [junit] 4: ?? (??:-1) [junit] 5: ?? (??:-1) [junit] 6: ?? (??:-1) [junit] 7: ?? (??:-1) [junit] 8: ?? (??:-1) [junit] 9: ?? (??:-1) [junit] 10: JNI_OnLoad (??:-1) [junit] 11: ?? (??:-1) [junit] 12: ?? (??:-1) [junit] 13: ?? (??:-1) [junit] 14: ?? (??:-1) [junit] 15: ?? (??:-1) [junit] 16: ?? (??:-1) [junit] 17: ?? (??:-1) [junit] 18: ?? (??:-1) [junit] end of stack trace [junit] Tests FAILED Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] none of kernel tests passed for the recent sources
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: guys - lets be clear. Are you unsetting it because it was pointing to Sun or BEA or IBM, or was it set to harmony? as for me JAVA_HOME refers to JRockit. have you tried setting it to harmony? yes, I did but w/o success: ... Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK ... Thanks, Vladimir. geir On Sep 19, 2006, at 7:01 AM, Egor Pasko wrote: I got almost the same recently. try 'unset JAVA_HOME' On the 0x1E9 day of Apache Harmony Dmitry Durnev wrote: I observe vm crash with the similar stack trace on my SUSE Linux box, when trying to launch Hello World app on debug version of DRLVM: *** glibc detected *** free(): invalid pointer: 0xbfffbde8 *** SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (??:-1) 5: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 6: properties_free (??:-1) 7: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 8: ?? (??:-1) 9: readClassPathFromPropertiesFile (??:-1) 10: ?? (??:-1) 11: ?? (??:-1) 12: ?? (??:-1) 13: ?? (??:-1) 14: ?? (??:-1) 15: _dl_runtime_resolve (??:-1) 16: ?? (??:-1) 17: JNI_OnLoad (??:-1) 18: ?? (??:-1) end of stack trace On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis \kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel tests now on Ubuntu 6, release build, and they are running fine. What platform? debug version on Windows platforms. I have no success on SUSE LINUX as well: ... -run-kernel-test-batch: [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/ lnx_ia32_gcc_debug/semis/kernel.tests/reports/batch.mode [junit] Running org.apache.harmony.lang.generics.ClassLoaderTest [junit] SIGSEGV in VM code. [junit] Stack trace: [junit] 1: properties_free (??:-1) [junit] 2: ?? (??:-1) [junit] 3: readClassPathFromPropertiesFile (??:-1) [junit] 4: ?? (??:-1) [junit] 5: ?? (??:-1) [junit] 6: ?? (??:-1) [junit] 7: ?? (??:-1) [junit] 8: ?? (??:-1) [junit] 9: ?? (??:-1) [junit] 10: JNI_OnLoad (??:-1) [junit] 11: ?? (??:-1) [junit] 12: ?? (??:-1) [junit] 13: ?? (??:-1) [junit] 14: ?? (??:-1) [junit] 15: ?? (??:-1) [junit] 16: ?? (??:-1) [junit] 17: ?? (??:-1) [junit] 18: ?? (??:-1) [junit] end of stack trace [junit] Tests FAILED Thanks, Vladimir. 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] -- Dmitry A. Durnev, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [drlvm] none of kernel tests passed for the recent sources
On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: guys - lets be clear. Are you unsetting it because it was pointing to Sun or BEA or IBM, or was it set to harmony? as for me JAVA_HOME refers to JRockit. have you tried setting it to harmony? yes, I did but w/o success: ... Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK ... I wanted to say I tried to run our tests (build.sh test) with this setting. If we need to set JAVA_HOME to the .../deploy/jre how we're going to get around this. Thanks, Vladimir. Thanks, Vladimir. geir On Sep 19, 2006, at 7:01 AM, Egor Pasko wrote: I got almost the same recently. try 'unset JAVA_HOME' On the 0x1E9 day of Apache Harmony Dmitry Durnev wrote: I observe vm crash with the similar stack trace on my SUSE Linux box, when trying to launch Hello World app on debug version of DRLVM: *** glibc detected *** free(): invalid pointer: 0xbfffbde8 *** SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (??:-1) 5: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 6: properties_free (??:-1) 7: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 8: ?? (??:-1) 9: readClassPathFromPropertiesFile (??:-1) 10: ?? (??:-1) 11: ?? (??:-1) 12: ?? (??:-1) 13: ?? (??:-1) 14: ?? (??:-1) 15: _dl_runtime_resolve (??:-1) 16: ?? (??:-1) 17: JNI_OnLoad (??:-1) 18: ?? (??:-1) end of stack trace On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis \kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel tests now on Ubuntu 6, release build, and they are running fine. What platform? debug version on Windows platforms. I have no success on SUSE LINUX as well: ... -run-kernel-test-batch: [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/ lnx_ia32_gcc_debug/semis/kernel.tests/reports/batch.mode [junit] Running org.apache.harmony.lang.generics.ClassLoaderTest [junit] SIGSEGV in VM code. [junit] Stack trace: [junit] 1: properties_free (??:-1) [junit] 2: ?? (??:-1) [junit] 3: readClassPathFromPropertiesFile (??:-1) [junit] 4: ?? (??:-1) [junit] 5: ?? (??:-1) [junit] 6: ?? (??:-1) [junit] 7: ?? (??:-1) [junit] 8: ?? (??:-1) [junit] 9: ?? (??:-1) [junit] 10: JNI_OnLoad (??:-1) [junit] 11: ?? (??:-1) [junit] 12: ?? (??:-1) [junit] 13: ?? (??:-1) [junit] 14: ?? (??:-1) [junit] 15: ?? (??:-1) [junit] 16: ?? (??:-1) [junit] 17: ?? (??:-1) [junit] 18: ?? (??:-1) [junit] end of stack trace [junit] Tests FAILED Thanks, Vladimir. 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] -- Dmitry A. Durnev, Intel Middleware Products Division - Terms
Re: [drlvm] none of kernel tests passed for the recent sources
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ok - my debug build on winXP just passed the c-unit tests and now is
winding through the smoke tests. Currently hanging on LOS
I doubt we'll be able to wait till this test ends. I've just excluded this
test from testing as follows:
Index: LOS.java
===
--- LOS.java (revision 447337)
+++ LOS.java (working copy)
@@ -23,6 +23,7 @@
/**
* Try large object allocation after filling the heap with small objects.
+ * @keyword XXX
*
*/
public class LOS extends Thread {
If you wish to reproduce my issue you should run the following command as I
mentioned starting this thread, namely:
*build.bat -Djunit.jar=%JUNIT_HOME% kernel.test*
Thanks,
Vladimir.
I can do
java -showversion -cp . Foo
(where Foo.class is in . of course)
and it works fine
geir
On Sep 19, 2006, at 5:43 AM, Vladimir Gorr wrote:
On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
Geir,
I found out none of the DRRVM kernel tests passed recently.
Although
all fine worked yet yesterday.
*build.bat -Djunit.jar=%JUNIT_HOME% kernel.test*
...
[echo]
[echo] ==
[echo] Run kernel tests using jitrino.jet
[echo] ==
[echo]
[mkdir] Created dir:
C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis\kernel.tests
\reports\jitrino.jet
[echo] RUNNING : java.lang.Class1_5Test
[junit] Test java.lang.Class1_5Test FAILED
[junit] Test java.lang.Class1_5Test FAILED
[echo] FAILED on reference JRE
[echo] RUNNING : java.lang.Class5Test
[junit] Test java.lang.Class5Test FAILED
[junit] Test java.lang.Class5Test FAILED
[echo] FAILED on reference JRE
[echo] RUNNING : java.lang.ClassAnnotationsTest
[junit] Test java.lang.ClassAnnotationsTest FAILED
^C
...
I suspect you can know a clue for this issue. Probably I missed
anything
and didn't note what was modifed.
Why are they failing? AS of yesterday, I thought they were all
passing
for me. I wouldn't have checked anything in if I saw that they were
failing en-masse. (We do need to have a stop the world as we
stabilize DRLVM, figure out why tests fail apparently randomly,
etc...)
Agree. I also try to understand this.
I'm running kernel tests now on Ubuntu 6, release build, and they are
running fine.
What platform?
debug version on Windows platforms. I have no success on SUSE LINUX
as well:
...
-run-kernel-test-batch:
[mkdir] Created dir:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/
lnx_ia32_gcc_debug/semis/kernel.tests/reports/batch.mode
[junit] Running org.apache.harmony.lang.generics.ClassLoaderTest
[junit] SIGSEGV in VM code.
[junit] Stack trace:
[junit] 1: properties_free (??:-1)
[junit] 2: ?? (??:-1)
[junit] 3: readClassPathFromPropertiesFile (??:-1)
[junit] 4: ?? (??:-1)
[junit] 5: ?? (??:-1)
[junit] 6: ?? (??:-1)
[junit] 7: ?? (??:-1)
[junit] 8: ?? (??:-1)
[junit] 9: ?? (??:-1)
[junit] 10: JNI_OnLoad (??:-1)
[junit] 11: ?? (??:-1)
[junit] 12: ?? (??:-1)
[junit] 13: ?? (??:-1)
[junit] 14: ?? (??:-1)
[junit] 15: ?? (??:-1)
[junit] 16: ?? (??:-1)
[junit] 17: ?? (??:-1)
[junit] 18: ?? (??:-1)
[junit] end of stack trace
[junit] Tests FAILED
Thanks,
Vladimir.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] none of kernel tests passed for the recent sources
On 9/19/06, Artem Aliev [EMAIL PROTECTED] wrote: is JAVA_HOME set to /deploy/jre this help, but the next is assert: #java /export/ali/svn-harmony/trunk/vm/thread/src/thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion1' failed. This bug is fixed in HARMONY-1340 issue There are olso a problems with 2 hythread lib in classlib and drlvm. The java launcher is dynamicly linked with classlib libhysig.so, that was built with classlib hythread lib. At runtime the libhysig.so is dynamicly linked with the DRLVM hythread lib. It looks like these hythread libs is not fully compatible. The first poroblem that was found is unimplemented hythread_exit() fumnction. I will develop patch for DRLVM hythread lib. Is it possible to use same hythread library for both classlib DRLVM? Thanks, Vladimir. Thanks Artem On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: That's good news (that you can reproduce it...) Is JAVA_HOME set to /deploy/jre ? geir On Sep 19, 2006, at 6:42 AM, Dmitry Durnev wrote: I observe vm crash with the similar stack trace on my SUSE Linux box, when trying to launch Hello World app on debug version of DRLVM: *** glibc detected *** free(): invalid pointer: 0xbfffbde8 *** SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (??:-1) 5: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 6: properties_free (??:-1) 7: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 8: ?? (??:-1) 9: readClassPathFromPropertiesFile (??:-1) 10: ?? (??:-1) 11: ?? (??:-1) 12: ?? (??:-1) 13: ?? (??:-1) 14: ?? (??:-1) 15: _dl_runtime_resolve (??:-1) 16: ?? (??:-1) 17: JNI_OnLoad (??:-1) 18: ?? (??:-1) end of stack trace On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis \kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel tests now on Ubuntu 6, release build, and they are running fine. What platform? debug version on Windows platforms. I have no success on SUSE LINUX as well: ... -run-kernel-test-batch: [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/ lnx_ia32_gcc_debug/semis/kernel.tests/reports/batch.mode [junit] Running org.apache.harmony.lang.generics.ClassLoaderTest [junit] SIGSEGV in VM code. [junit] Stack trace: [junit] 1: properties_free (??:-1) [junit] 2: ?? (??:-1) [junit] 3: readClassPathFromPropertiesFile (??:-1) [junit] 4: ?? (??:-1) [junit] 5: ?? (??:-1) [junit] 6: ?? (??:-1) [junit] 7: ?? (??:-1) [junit] 8: ?? (??:-1) [junit] 9: ?? (??:-1) [junit] 10: JNI_OnLoad (??:-1) [junit] 11: ?? (??:-1) [junit] 12: ?? (??:-1) [junit] 13: ?? (??:-1) [junit] 14: ?? (??:-1) [junit] 15: ?? (??:-1) [junit] 16: ?? (??:-1) [junit] 17: ?? (??:-1) [junit] 18: ?? (??:-1) [junit] end of stack trace [junit] Tests FAILED Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony
Re: [drlvm] none of kernel tests passed for the recent sources
On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Artem Aliev [EMAIL PROTECTED] wrote: is JAVA_HOME set to /deploy/jre this help, but the next is assert: #java /export/ali/svn-harmony/trunk/vm/thread/src/thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion1' failed. This bug is fixed in HARMONY-1340 issue There are olso a problems with 2 hythread lib in classlib and drlvm. The java launcher is dynamicly linked with classlib libhysig.so, that was built with classlib hythread lib. At runtime the libhysig.so is dynamicly linked with the DRLVM hythread lib. It looks like these hythread libs is not fully compatible. The first poroblem that was found is unimplemented hythread_exit() fumnction. I will develop patch for DRLVM hythread lib. Is it possible to use same hythread library for both classlib DRLVM? Oops... I didn't note new thread started for this :-(. All untwists very dynamically. Thanks, Vladimir. Thanks Artem On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: That's good news (that you can reproduce it...) Is JAVA_HOME set to /deploy/jre ? geir On Sep 19, 2006, at 6:42 AM, Dmitry Durnev wrote: I observe vm crash with the similar stack trace on my SUSE Linux box, when trying to launch Hello World app on debug version of DRLVM: *** glibc detected *** free(): invalid pointer: 0xbfffbde8 *** SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (??:-1) 5: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 6: properties_free (??:-1) 7: find_call_JNI_OnLoad (/export/workspace/drlvm/vm/vmcore/src/util/natives_support.cpp:117) 8: ?? (??:-1) 9: readClassPathFromPropertiesFile (??:-1) 10: ?? (??:-1) 11: ?? (??:-1) 12: ?? (??:-1) 13: ?? (??:-1) 14: ?? (??:-1) 15: _dl_runtime_resolve (??:-1) 16: ?? (??:-1) 17: JNI_OnLoad (??:-1) 18: ?? (??:-1) end of stack trace On 9/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Geir, I found out none of the DRRVM kernel tests passed recently. Although all fine worked yet yesterday. *build.bat -Djunit.jar=%JUNIT_HOME% kernel.test* ... [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: C:\DrlSrc\drlvm\trunk\build\win_ia32_msvc_debug\semis \kernel.tests\reports\jitrino.jet [echo] RUNNING : java.lang.Class1_5Test [junit] Test java.lang.Class1_5Test FAILED [junit] Test java.lang.Class1_5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.Class5Test [junit] Test java.lang.Class5Test FAILED [junit] Test java.lang.Class5Test FAILED [echo] FAILED on reference JRE [echo] RUNNING : java.lang.ClassAnnotationsTest [junit] Test java.lang.ClassAnnotationsTest FAILED ^C ... I suspect you can know a clue for this issue. Probably I missed anything and didn't note what was modifed. Why are they failing? AS of yesterday, I thought they were all passing for me. I wouldn't have checked anything in if I saw that they were failing en-masse. (We do need to have a stop the world as we stabilize DRLVM, figure out why tests fail apparently randomly, etc...) Agree. I also try to understand this. I'm running kernel tests now on Ubuntu 6, release build, and they are running fine. What platform? debug version on Windows platforms. I have no success on SUSE LINUX as well: ... -run-kernel-test-batch: [mkdir] Created dir: /nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/build/ lnx_ia32_gcc_debug/semis/kernel.tests/reports/batch.mode [junit] Running org.apache.harmony.lang.generics.ClassLoaderTest [junit] SIGSEGV in VM code. [junit] Stack trace: [junit] 1: properties_free (??:-1) [junit] 2: ?? (??:-1) [junit] 3: readClassPathFromPropertiesFile (??:-1) [junit] 4: ?? (??:-1) [junit] 5: ?? (??:-1) [junit] 6: ?? (??:-1) [junit] 7: ?? (??:-1) [junit] 8: ?? (??:-1) [junit] 9: ?? (??:-1) [junit] 10: JNI_OnLoad (??:-1) [junit] 11: ?? (??:-1) [junit] 12: ?? (??:-1) [junit] 13: ?? (??:-1) [junit] 14: ?? (??:-1) [junit] 15: ?? (??:-1) [junit] 16: ?? (??:-1
[drlvm] build fails at revision 447316
Does anybody observe this DRLVM build issue at the revision 447316? ... build.native.cpp: [cc] 2 total files to be compiled. [cc] cl : Command line warning D4025 : overriding '/Ox' with '/Od' [cc] j9vmls.cpp [cc] C:\DrlSrc\drlvm\trunk\vm\vmi\src\j9vmls.cpp(20) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\DrlSrc\drlvm\trunk\vm\vmi\src\vmi.cpp(25) : fatal error C1083: Cannot open include file: 'zipsup.h': No such file or directory [cc] Generating Code... Thanks, Vladimir.
Re: [drlvm] build fails at revision 447316
On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ah! Probably build/drlvm.properties that I added, which will point your build off into nowhere for classlib if not setup right (which is where those headers come from...) Just do a svn update - I renamed to drlvm.properties.example to make it less harmful. Sorry about that. No problems with this. Just I'd like to mention I have the recent sources. I was able to successfully build after cleaning (build.bat clean; build.bat ). In any case thanks for your help, Vladimir. geir Vladimir Gorr wrote: Does anybody observe this DRLVM build issue at the revision 447316? ... build.native.cpp: [cc] 2 total files to be compiled. [cc] cl : Command line warning D4025 : overriding '/Ox' with '/Od' [cc] j9vmls.cpp [cc] C:\DrlSrc\drlvm\trunk\vm\vmi\src\j9vmls.cpp(20) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\DrlSrc\drlvm\trunk\vm\vmi\src\vmi.cpp(25) : fatal error C1083: Cannot open include file: 'zipsup.h': No such file or directory [cc] Generating Code... Thanks, Vladimir. - 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On 9/15/06, Mark Hindess [EMAIL PROTECTED] wrote: On 15 September 2006 at 12:18, Vladimir Gorr [EMAIL PROTECTED] wrote: I'd like to add some words ... IMO each contributor should be responsible his patch can be applied w/o any problems. That's why he should check these patches and run the tests before filling new JIRA issue. However nobody can guarantee either patch will be successfully applied later due to the possible conflicts. Therefore it'd be not bad to have a reference to the revision number this patch has been created for. I suppose it will lighten the work for committers. Does it make sense? Yes. But the patch metadata usually contains this information - assuming people are using svn diff to create the diffs. Indeed someone of contributors can use another tool (say, GIT) to prepare their patches. It's a reason why I mentioned about the revision number. Thanks, Vladimir. -Mark. On 9/14/06, Mark Hindess [EMAIL PROTECTED] wrote: Just thought of another item. I've seen a patch recently where a move was encapsulated in the patch. We should encourage contributions to supply recipes/scripts for svn move commands rather than non-atomic deletions and additions in patches. -Mark. On 14 September 2006 at 14:29, Mark Hindess [EMAIL PROTECTED] wrote: On 14 September 2006 at 17:13, Alexey Petrenko [EMAIL PROTECTED] wrote: Agree on both cases. We can also ask to use dos2unix utility on Windows to convert patches to unix LF fromat. I'm actually less worried about this one. I tend to be able to get any patch to work under linux using either dos2unix or using: perl -pe '/^(Index||---|\+\+\+|[EMAIL PROTECTED]@)/s/\r//;' to remove the CR characters only from the metadata. The latter will become obsolete when we sort out the eol problems in svn. -Mark. SY, Alexey 2006/9/14, Mark Hindess [EMAIL PROTECTED]: I'd suggest two further things. First, we change the default JIRA priority to something lower than 'Major'. Currently most come in as 'Major' even if they are trivial edge cases that might never affect an application. I assume because people are just leaving the default unchanged without giving it much thought. If we change the default, then the guidelines could suggest only raising the priority if the bug affects a real application. Second, can we ask that all patches be relative to either the top-level (where the main build.xml is) or modules/module-name (where a modules build.xml is). It bothers me when I see patches with files that start with trunk/modules/... rather than trunk because I worry about just how much these people are checking out. At the other end of the spectrum it takes much longer to apply a JIRA if, for example, I have to change directory to modules/awt/src/test/api/java/common/java/awt/geom to apply the test patch and then change directory modules/awt/src/main/java/common/java/awt/geom to apply the fix. Don't get me wrong though, I'm grateful for all bug reports and patches but if we can make things a little more efficient then perhaps we might get through them more quickly. Regards, Mark. On 14 September 2006 at 11:33, Oliver Deakin [EMAIL PROTECTED] m wrote: Thanks Alexey - I think these guidelines will be helpful for all of us, whether opening, fixing or committing bugs and patches. Just a couple of extra comments. Alexey Petrenko wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help communit y to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patc h to test will be highly appreciated. 1a. Provide plenty of information about steps necessary to recreate the bug. If a patch for the fix has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc.). 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create i t. 2.1.2
Re: [drlvm] HARMONY-1363 - status update
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I now have things building and running with the 1363 patch - more work for the launcher was needed. I'm now using the harmonyvm.properties file in the vmdir, and this is working well. I am now able to run tests, although I have one failure in StackTest, and interestingly, the new testsuite that came with the thread manager isn't running. This problem will disappear after applying the H-1431 patch. Thanks, Vladimir. So progress. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I'd like to add some words ... IMO each contributor should be responsible his patch can be applied w/o any problems. That's why he should check these patches and run the tests before filling new JIRA issue. However nobody can guarantee either patch will be successfully applied later due to the possible conflicts. Therefore it'd be not bad to have a reference to the revision number this patch has been created for. I suppose it will lighten the work for committers. Does it make sense? Thanks, Vladimir. On 9/14/06, Mark Hindess [EMAIL PROTECTED] wrote: Just thought of another item. I've seen a patch recently where a move was encapsulated in the patch. We should encourage contributions to supply recipes/scripts for svn move commands rather than non-atomic deletions and additions in patches. -Mark. On 14 September 2006 at 14:29, Mark Hindess [EMAIL PROTECTED] wrote: On 14 September 2006 at 17:13, Alexey Petrenko [EMAIL PROTECTED] wrote: Agree on both cases. We can also ask to use dos2unix utility on Windows to convert patches to unix LF fromat. I'm actually less worried about this one. I tend to be able to get any patch to work under linux using either dos2unix or using: perl -pe '/^(Index||---|\+\+\+|[EMAIL PROTECTED]@)/s/\r//;' to remove the CR characters only from the metadata. The latter will become obsolete when we sort out the eol problems in svn. -Mark. SY, Alexey 2006/9/14, Mark Hindess [EMAIL PROTECTED]: I'd suggest two further things. First, we change the default JIRA priority to something lower than 'Major'. Currently most come in as 'Major' even if they are trivial edge cases that might never affect an application. I assume because people are just leaving the default unchanged without giving it much thought. If we change the default, then the guidelines could suggest only raising the priority if the bug affects a real application. Second, can we ask that all patches be relative to either the top-level (where the main build.xml is) or modules/module-name (where a modules build.xml is). It bothers me when I see patches with files that start with trunk/modules/... rather than trunk because I worry about just how much these people are checking out. At the other end of the spectrum it takes much longer to apply a JIRA if, for example, I have to change directory to modules/awt/src/test/api/java/common/java/awt/geom to apply the test patch and then change directory modules/awt/src/main/java/common/java/awt/geom to apply the fix. Don't get me wrong though, I'm grateful for all bug reports and patches but if we can make things a little more efficient then perhaps we might get through them more quickly. Regards, Mark. On 14 September 2006 at 11:33, Oliver Deakin [EMAIL PROTECTED] m wrote: Thanks Alexey - I think these guidelines will be helpful for all of us, whether opening, fixing or committing bugs and patches. Just a couple of extra comments. Alexey Petrenko wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help communit y to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patc h to test will be highly appreciated. 1a. Provide plenty of information about steps necessary to recreate the bug. If a patch for the fix has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc.). 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create i t. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. We should also add a step here to say add a comment to the JIRA indicating that you are working on this bug, as suggested by Geir at [1]. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.m bo x/%3 [EMAIL PROTECTED] 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: clos e the
Re: [drlvm] Need help debugging
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ) for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first :)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of 'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment
this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory
alocated
with hymem_allocate_memory get somehow broken on exit from a
method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I
suspect
it may
be because the patch modifies the LOS test, but I'm not so
sure.
that patch (HARMONY-1269) is a sole-author patch to our
existing
codebase, and while I do have a BCC to put in SVN, I think
that
this is
a patch, and not a bulk contribution, so I'll go forward and
commit
it.
geir
Geir Magnusson Jr. wrote:
More news - I'm not passing the smoke tests. gc.LOC just
spins
(and
sucks a lot of memory in).
Clearly what I thought were trivial changes to switch to use
the
launcher had hidden effects. Any suggestions where to start
looking?
geir
Re: [drlvm] Need help debugging
Probably, you didn't note I've commented this fragment of code (firts last
lines).
Sorry I didn't mention about this before. After these changes I could
sucessfully start the ActiveMQ.
Before I have the following error:
Assertion failed: size = skip
Trying to skip 6 frames but there are only 5 frames in stack
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/kernel_classes/native/org_apache_harmony_vm_VMStack.cpp:301:
_jobject* Java_org_apache_harmony_vm_VMStack_getStackTrace(JNIEnv*,
_jobject*, _jobject*): Assertion `size = skip' failed.
abort_handler()
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm a little skeptical, as I had that change in before you first tested
and found a problem, right?
geir
Vladimir Gorr wrote:
vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp
...
* /*
*// skip Thread.runImpl()
size--;
// skip the VMStart$MainThread if one exits from the bottom of the
stack
// along with 2 reflection frames used to invoke method main
static String* starter_String =
genv-string_pool.lookup(java/lang/VMStart$MainThread);
Method_Handle method = frames[size].method;
assert(method);
// skip only for main application thread
if (!strcmp(method_get_name(method), runImpl)
method-get_class()-name == starter_String) {
int rem = size - skip-1;
size -= rem 2 ? rem : 2;
}
ASSERT(size = skip, Trying to skip skip
frames but there are only
size frames in stack);
**/*
...
Thanks,
Vladimir.
On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I was able to sucessfully run both applications (Eclipse ActiveMQ)
for
the
recent build.
what changed?
geir
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first
:)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value
is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from
the
SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM
crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on
DRLVM
+
Classlibrary build 442240 .
The problem I see first is that in
classlib
root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of
'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can
comment
this
out because memory for mainClassJar is already allocated in
the
calling
Re: [drlvm] Need help debugging
Did you run this application for the recent binaries got from the SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on DRLVM +
Classlibrary build 442240 .
The problem I see first is that in
classlib root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs' variable
'mainClassJar' contains garbale while in the very end of 'static int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar = hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory alocated
with hymem_allocate_memory get somehow broken on exit from a method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I suspect it may
be because the patch modifies the LOS test, but I'm not so sure.
that patch (HARMONY-1269) is a sole-author patch to our existing
codebase, and while I do have a BCC to put in SVN, I think that this is
a patch, and not a bulk contribution, so I'll go forward and commit
it.
geir
Geir Magnusson Jr. wrote:
More news - I'm not passing the smoke tests. gc.LOC just spins (and
sucks a lot of memory in).
Clearly what I thought were trivial changes to switch to use the
launcher had hidden effects. Any suggestions where to start looking?
geir
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy, but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and there
doesn't seem to be any errors, but I don't know what to look for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
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]
--
Regards,
Anton Luht,
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] Need help debugging
No needs to use the jar option because drlvm analogously fails on Windows
for the following:
java -version
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from the SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes for
both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on DRLVM +
Classlibrary build 442240 .
The problem I see first is that in
classlib root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of 'static int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar = hymem_allocate_memory
(50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory
alocated
with hymem_allocate_memory get somehow broken on exit from a method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I suspect
it may
be because the patch modifies the LOS test, but I'm not so sure.
that patch (HARMONY-1269) is a sole-author patch to our existing
codebase, and while I do have a BCC to put in SVN, I think that
this is
a patch, and not a bulk contribution, so I'll go forward and
commit
it.
geir
Geir Magnusson Jr. wrote:
More news - I'm not passing the smoke tests. gc.LOC just spins
(and
sucks a lot of memory in).
Clearly what I thought were trivial changes to switch to use the
launcher had hidden effects. Any suggestions where to start
looking?
geir
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is
seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat
ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the
program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy,
but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and
there
doesn't seem to be any errors, but I don't know what to look
for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
--
Regards,
Anton Luht,
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] Need help debugging
I was able to sucessfully run both applications (Eclipse ActiveMQ) for the
recent build.
Thanks,
Vladimir.
On 9/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
doh. Thanks. I feel dumb for not trying the simplest thing first :)
There's a test...
geir
Anton Luht wrote:
Hello,
The 'java -jar' launcher prints dump and exits even on a minimal
HelloWorld app jar - please see
http://issues.apache.org/jira/browse/HARMONY-1444
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
No, I used hand-made build from SVN.
BTW, sorry for confusion about 'broken data'. The pointer value is
changed inside the method - this assignment should be removed.
On 9/12/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Did you run this application for the recent binaries got from the SVN
sources?
As for me my results differ from Geir ones, namely, DRLVM crashes
for both
Windows Linux as follows:
===
Windows
===
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo JAVA_HOME
JAVA_HOME
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ echo $CLASSPATH
c:/Tools/incubator-activemq-4.0/lib
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ which java
/cygdrive/c/DrlSrc/drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/java
vgorr@ /cygdrive/c/Tools/incubator-activemq-4.0
$ bin/activemq
cygpath: can't convert empty path
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=00F3D648
ContextFlags=0001003f
Handler1=00401010
Handler2=11105D20
InaccessibleAddress=00F3D648
EDI=0013F9D4
ESI=0013F768
EAX=
EBX=000B
ECX=0001
EDX=000C
EIP=00F3D648
ESP=0013F764
EBP=0013F770
Module=
Module_base_address=00F3
Offset_in_DLL=d648
Linux
sh bin/activemq
java:
/nfs/ins/proj/drl/coreapi/vgorr/drlvm/trunk/vm/vmcore/src/exception/exceptions.cpp:143:
_jobject* create_exception(const char*): Assertion
`hythread_is_suspend_enabled()' failed.
abort_handler()
Aborted
Thanks,
Vladimir.
On 9/12/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'm observing the same problem - ActiveMQ can't start - on DRLVM +
Classlibrary build 442240 .
The problem I see first is that in
classlib root\modules\luni\src\main\native\launcher\shared\main.c
in function 'static int invocation' after call 'createVMArgs'
variable
'mainClassJar' contains garbale while in the very end of 'static
int
createVMArgs' it contains valid string
'org.apache.harmony.kernel.vm.JarRunner' . If we comment out
'hymem_allocate_memory' in that function:
if (isStandaloneJar)
{
if (useDefaultJarRunner == 0)
{
//:::commented out mainClassJar =
hymem_allocate_memory (50);
if (mainClassJar == NULL)
the application will crash a little later. Note: we can comment
this
out because memory for mainClassJar is already allocated in the
calling method.
I believe that the general problem is that contents of memory
alocated
with hymem_allocate_memory get somehow broken on exit from a
method.
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I applied the GCv4.1 patch and now I pass smoke test. I suspect
it may
be because the patch modifies the LOS test, but I'm not so sure.
that patch (HARMONY-1269) is a sole-author patch to our existing
codebase, and while I do have a BCC to put in SVN, I think that
this is
a patch, and not a bulk contribution, so I'll go forward and
commit
it.
geir
Geir Magnusson Jr. wrote:
More news - I'm not passing the smoke tests. gc.LOC just spins
(and
sucks a lot of memory in).
Clearly what I thought were trivial changes to switch to use
the
launcher had hidden effects. Any suggestions where to start
looking?
geir
Geir Magnusson Jr. wrote:
I was testing the DRLVM-in-Launcher setup and something is
seriously
broken.
On Ubuntu, both debug and release builds, it will run Tomcat
ok, but
when I try something like Eclipse 3.2 or ActiveMQ 4.0.2 the
program
runs and silently exits. No log output, no console output.
I've been trying to find a hint of what is making it unhappy,
but so
far, no luck.
I've been staring at the output with -Xlog and -Xtrace, and
there
doesn't seem to be any errors, but I don't know what to look
for. (
I've captured the stream and placed it here :
http://people.apache.org/~geirm/activemq-logstream-20060909.txt
http://people.apache.org/~geirm/activemq-tracestream-20060909.txt
If anyone has any hints, I'd be mighty obliged...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL
[classlib] recent build fails on Windows
Could anybody please explain me why the classlib build fails on Windows platform as follows: ... [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -FIsehmap.h-D_X 86_=1 -DWIN32 -D_WIN32 -W3 -D_WIN95 -D_WIN32_WINDOWS=0x0400 /D_WIN32_DCOM -D_WI N32_IE=0x0500 -DWINVER=0x0400 -Ogityb1 -W3 -GF -Gs -MD -Zi -Zm400 -D_DLL -D_MT -DWIN32 -D_WIN32_WINNT=0x0400 -D_WINSOCKAPI_ -DWINVER=0x0400 /IC:\DrlSrc\classlib\trunk\deploy\include /IC:\DrlSrc\classlib\trunk\deploy\jdk\include /I. -FoWinDataTransfer.obj WinDataTransfer.cpp [exec] Microsoft (R) Program Maintenance Utility Version 7.10.3077 [exec] Copyright (C) Microsoft Corporation. All rights reserved. [exec] WinDataTransfer.cpp [exec] WinDataTransfer.cpp(22) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory [exec] NMAKE : fatal error U1077: 'cl' : return code '0x2' [exec] Stop. How can I resolve this issue? Thanks in advance, Vladimir.
Re: [classlib] recent build fails on Windows
Thanks, Alexey, it helped. Vladimir. On 9/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote: It fails because you should add path to MS ALTMFC library to your INCLUDE and LIB variables. You can set this variables by vcvars32.bat from MSVC installation. SY, Alexey 2006/9/12, Vladimir Gorr [EMAIL PROTECTED]: Could anybody please explain me why the classlib build fails on Windows platform as follows: ... [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo - FIsehmap.h-D_X 86_=1 -DWIN32 -D_WIN32 -W3 -D_WIN95 -D_WIN32_WINDOWS=0x0400 /D_WIN32_DCOM -D_WI N32_IE=0x0500 -DWINVER=0x0400 -Ogityb1 -W3 -GF -Gs -MD -Zi -Zm400 -D_DLL -D_MT -DWIN32 -D_WIN32_WINNT=0x0400 -D_WINSOCKAPI_ -DWINVER=0x0400 /IC:\DrlSrc\classlib\trunk\deploy\include /IC:\DrlSrc\classlib\trunk\deploy\jdk\include /I. -FoWinDataTransfer.obj WinDataTransfer.cpp [exec] Microsoft (R) Program Maintenance Utility Version 7.10.3077 [exec] Copyright (C) Microsoft Corporation. All rights reserved. [exec] WinDataTransfer.cpp [exec] WinDataTransfer.cpp(22) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory [exec] NMAKE : fatal error U1077: 'cl' : return code '0x2' [exec] Stop. How can I resolve this issue? Thanks in advance, Vladimir. -- 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: [app] ant with ecj
Indeed this issue exists if JAVA_HOME refers to Harmony JRE:
echo $JAVA_HOME
.../classlib/trunk/deploy/jdk/jre
echo $LD_LIBRARY_PATH
.../classlib/trunk/deploy/jdk/jre/bin
echo $CLASSPATH=.../classlib/trunk/depends/jars/ecj_3.2/ecj_3.2.jar
ant -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
...
[javac] 3608. ERROR in
/nfs/ins/proj/drl/coreapi/vgorr/GIT/classlib/trunk/modules/text/src/main/java/java/text/DecimalFormat.java
[javac] (at line 23)
[javac] import java.math.BigDecimal;
...
It means our build system doesn't work correspondingly for the self-hosting
mode.
Besides I'd like to note a lot of warning are generated when we use ECJ3.2.
Thanks,
Vladimir.
On 8/28/06, Jordan Justen [EMAIL PROTECTED] wrote:
My JAVA_HOME is set to harmony/jdk/jre.
Are you sure ant is running with harmony's jvm and classlibs when
JAVA_HOME
is set to sun's path?
I am wanting to use the harmony classlibs and jvm with ant and the ecj
compiler. Hopefully this would make no dependencies on sun's java.
You know what. I didn't explicitly mention that I was trying to run this
with harmony. Whoops, sorry.
-Jordan
On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote:
The current build scripts should be doing this already. For example,
this
is
a snippet from the 'luni' module's build script.
javac sourcepath=
srcdir=${hy.luni.src.main.java}
destdir=${hy.build}
source=${hy.javac.source}
target=${hy.javac.target}
debug=${hy.javac.debug}
bootclasspath
fileset dir=${hy.jdk}/jre/lib/boot
include name=**/*.jar /
/fileset
/bootclasspath
/javac
It points to luni's source directory and puts everything in the deploy
(JDK)/jre/lib/boot folder on the bootclasspath to compile against. In
the
case of java.lang.Object, this should be in the luni-kernel-stubs.jar
.
If you're doing a full compile, then java.lang.Object should be
included
in the source files.
I just ran the build using the Eclipse compiler and it worked fine.
Here's
what I did.
1. Check out all of the code from the classlib trunk [1] down. You need
everything from the folder down.
2. From the 'trunk' folder, run 'ant fetch-depends', which downloads all
of
the dependencies for the build.
3. Grab the ecj_3.2.jar from the 'trunk/depends/jars/ecj_3.2' and copied
it
into my ANT_HOME/lib folder. This puts ECJ on Ant's classpath.
4. From the 'trunk' folder, run 'ant build
-Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter' and the entire
federated build runs.
Is this similar to what you're doing? Note, I'm running Ant with
JAVA_HOME
pointing to Sun's 5.0_7 JDK.
-Nathan
[1]
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/
-Original Message-
From: Jordan Justen [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 27, 2006 10:31 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [app] ant with ecj
Nathan,
Is there a way to have the javac/ecj task include all of standard
harmony
jars without including them in the CLASSPATH environment variable?
Thanks,
-Jordan
On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Keep in mind that the execution of the Ant scripts and the
compilation
are
two separate things, which means they are using two different
classpaths.
If
the compilation task is complaining about a missing class, then this
means
the class is missing from the classpath of the compiler, not the
classpath
of the executing Ant. You'll need the Eclipse compiler JAR on Ant's
execution classpath to execute the javac task.
This can be confusing when using the Eclipse compiler, since it
doesn't
have
any default classpath. Normally when you're using 'javac' from a
JDK,
the
classpath of the underlying JRE (all of the java.*, etc classes) is
automatically on the classpath. The Eclipse compiler is not part of
a
JDK,
so there is nothing on the classpath by default.
-Nathan
-Original Message-
From: Jordan Justen [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 27, 2006 8:49 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [app] ant with ecj
Richard,
Yes, I also added ecj_3.2.jar to the CLASSPATH.
Ant works fine, but the first time a javac task is encountered,
the
compiler
complained that java.lang.Object was not found. I then added
jdk/jre/lib/boot/kernel.jar to CLASSPATH. Now, I see an error
that
java.lang.String is not found, so I added luni.jar to CLASSPATH.
etc...
Since ant is basically working (mkdir tasks, delete tasks, java
tasks
all
seem to work), I think the harmony jvm is loading these boot
jars,
but
it
seems like when the javac task uses ecj, those jars are not
visible.
I'm using windows xp, ant 1.6.5, and the
Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
I see these improvements don't contain very important thing allowing us to automatically build (or get) the gl library. Or is this another story? Otherwise only the advanced people can look at these enhancements :-). Nevertheless +1 for me. Thanks, Vladimir. On 8/28/06, Alexey Petrenko [EMAIL PROTECTED] wrote: +1 2006/8/28, Geir Magnusson Jr [EMAIL PROTECTED]: +1 Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 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] -- 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: [kernel][reflect] Should we copy bug of RI JVM ?
On 8/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
There is a test[1] in classlib, which verifies that reflection access
from enclosing class to a private member of a nested class results in
IllegalAccessException.
However, this is against the language specification (para 6.6.1 of the
JLS3):
if the member or constructor is declared private, then access is
permitted if and only if it occurs within the body of the top level class
(§7.6)
that encloses the declaration of the member or constructor.
Moreover, the following test reveals inconsistency between standard
access control and reflective one:
-
class NestedAccessTest {
static class A {
private static int x = 123;
}
public static void main(String... s) throws Throwable{
System.out.println(A.x);
System.out.println(A.class.getDeclaredField(x).get(null));
}
}
java -showversion NestedAccessTest
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
123
Exception in thread main java.lang.IllegalAccessException: Class
NestedAccessTest can not access a member of class NestedAccessTest$A
with modifiers private static
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Field.doSecurityCheck(Field.java:954)
at java.lang.reflect.Field.getFieldAccessor(Field.java:895)
at java.lang.reflect.Field.get(Field.java:357)
at NestedAccessTest.main(NestedAccessTest.java:7)
--
I found out, this is an acknowledged bug of RI [2], and is ranked TOP#6.
The good news, however, that DRLVM is free of this defect. OTOH, it
surely cannot pass the aforementioned test of the classlib.
So the question: should we fix the test and will IBM VME address this
issue? What is appropriate JIRA category for it?
I suppose this test should be modified after IBM VME will behave in
accordance with the specifications if any.
Certainly, if there are no any objections. IMO we should avoid any bugs
known for the RI, shouldn't we?
Thanks,
Vladimir.
[1]testcase classname=tests.api.java.lang.reflect.FieldTest
name=test_getLjava_lang_Object/
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
--
Alexey Varlamov
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm] ArgoUML application crashes IBM VME
On 8/24/06, Oliver Deakin [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 8/23/06, Oliver Deakin [EMAIL PROTECTED] wrote: Hi Vladimir, Ive taken a quick look at your bug report, and at first glance the Windows stack trace says: Caused by: java.lang.UnsatisfiedLinkError: gl (Not found in com.ibm.oti.vm.bootstrap.library.path) at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:113) at java.lang.ClassLoader.loadLibraryWithClassLoader( ClassLoader.java:97) at java.lang.System.loadLibrary(System.java:758) at org.apache.harmony.awt.gl.windows.WinGraphicsEnvironment .clinit(WiGraphicsEnvironment.java:38) which basically tells me that you are missing gl.dll. In fact, if you look at WinGraphicsEnvironment at line 38, there is a System.loadLibrary (gl) call. You need to build with the -Dwith.awt.swing=true flag set on the ant command line to get this. If you do this and rerun argouml, the app. splash screen comes up, but is halted after a short time by the following error: Exception in thread main java.lang.reflect.InvocationTargetException at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:27) at java.lang.reflect.Method.invoke(Method.java:258) at com.ibm.oti.vm.JarRunner.main(JarRunner.java:42) Caused by: java.lang.NoSuchMethodError: java/applet/Applet.getAppletContext()Ljava/applet/AppletContext; at org.tigris.gef.base.Globals.getAppletContext(Globals.java:86) at org.tigris.gef.base.Globals.showStatus(Globals.java:145) at org.tigris.gef.base.Editor.pushMode(Editor.java:282) at org.tigris.gef.base.Editor.init(Editor.java:191) at org.tigris.gef.base.Editor.init(Editor.java:172) SNIP! which is not a surprise since our Applet class is just an empty shell. Looks like we cannot run this until we have Applet. It might be interesting if you ran one of the class load investigation tools contributed to Harmony (I think there might be two) to see how far away we are from running this - perhaps the results could be added to the website? The JIRAs containing these tools are listed at the bottom of [1] Uhhh... It's not very easy to build GL on Windows. Obviously this process should (and can) be rendered automatic. I hope it can ;) Oliver, I've got same result as you have. I also have info about all classes have not been implemented in the Harmony for this application (argoUML). At least the filter_classes tool (H-165) generates the following list: Great! Thanks for getting this list together. I guess these should all be covered by our xerces dependency - so it appears that the only thing standing between us and running ArgoUML is the Applet implementation? I'm slightly unsure. We need to develop the Applet to understand this. I mean new unimplemented classes can be found out after the InvocationTargetException disappers. Is there somewhere you can put this on the wiki/website so that we dont lose it? Looks like an interesting test app. Yes, it makes sense, I think. Although I don't know what the right place is? Thanks, Vladimir. Regards, Oliver cat missing_classes.txt javax/xml/parsers/SAXParserFactory javax/xml/parsers/ParserConfigurationException javax/xml/parsers/DocumentBuilderFactory javax/xml/parsers/DocumentBuilder javax/xml/parsers/SAXParser javax/xml/transform/Source javax/xml/transform/Result javax/xml/transform/TransformerException javax/xml/transform/TransformerConfigurationException org/w3c/dom/Node org/w3c/dom/NodeList org/w3c/dom/Document org/w3c/dom/Element org/w3c/dom/TypeInfo org/w3c/dom/CharacterData org/w3c/dom/Comment org/w3c/dom/DocumentType org/w3c/dom/NamedNodeMap org/w3c/dom/Attr org/w3c/dom/Text org/w3c/dom/events/EventTarget org/w3c/dom/events/DocumentEvent org/xml/sax/AttributeList org/xml/sax/EntityResolver org/xml/sax/InputSource org/xml/sax/SAXException org/xml/sax/DTDHandler org/xml/sax/ContentHandler org/xml/sax/ErrorHandler org/xml/sax/Parser org/xml/sax/XMLReader org/xml/sax/Attributes org/xml/sax/Locator org/xml/sax/ext/EntityResolver2 org/xml/sax/ext/Attributes2 org/xml/sax/ext/Locator2 org/xml/sax/helpers/DefaultHandler org/xml/sax/helpers/AttributesImpl Thanks, Vladimir. I will take a look at the Linux crash next and see if I can get anywhere with that. Ill add the above stack trace to the JIRA. Regards, Oli [1] http://incubator.apache.org/harmony/roadmap.html Vladimir Gorr wrote: ArgoUML application (http://argouml.tigris.org) crashes IBM VME. I've created new issue (H-1257) where the logs are. Could anybody please look at this problem and fix it? Thanks, Vladimir. -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: [vm] ArgoUML application crashes IBM VME
On 8/23/06, Oliver Deakin [EMAIL PROTECTED] wrote: Hi Vladimir, Ive taken a quick look at your bug report, and at first glance the Windows stack trace says: Caused by: java.lang.UnsatisfiedLinkError: gl (Not found in com.ibm.oti.vm.bootstrap.library.path) at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:113) at java.lang.ClassLoader.loadLibraryWithClassLoader( ClassLoader.java:97) at java.lang.System.loadLibrary(System.java:758) at org.apache.harmony.awt.gl.windows.WinGraphicsEnvironment .clinit(WiGraphicsEnvironment.java:38) which basically tells me that you are missing gl.dll. In fact, if you look at WinGraphicsEnvironment at line 38, there is a System.loadLibrary (gl) call. You need to build with the -Dwith.awt.swing=true flag set on the ant command line to get this. If you do this and rerun argouml, the app. splash screen comes up, but is halted after a short time by the following error: Exception in thread main java.lang.reflect.InvocationTargetException at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:27) at java.lang.reflect.Method.invoke(Method.java:258) at com.ibm.oti.vm.JarRunner.main(JarRunner.java:42) Caused by: java.lang.NoSuchMethodError: java/applet/Applet.getAppletContext()Ljava/applet/AppletContext; at org.tigris.gef.base.Globals.getAppletContext(Globals.java:86) at org.tigris.gef.base.Globals.showStatus(Globals.java:145) at org.tigris.gef.base.Editor.pushMode(Editor.java:282) at org.tigris.gef.base.Editor.init(Editor.java:191) at org.tigris.gef.base.Editor.init(Editor.java:172) SNIP! which is not a surprise since our Applet class is just an empty shell. Looks like we cannot run this until we have Applet. It might be interesting if you ran one of the class load investigation tools contributed to Harmony (I think there might be two) to see how far away we are from running this - perhaps the results could be added to the website? The JIRAs containing these tools are listed at the bottom of [1] Uhhh... It's not very easy to build GL on Windows. Obviously this process should (and can) be rendered automatic. Oliver, I've got same result as you have. I also have info about all classes have not been implemented in the Harmony for this application (argoUML). At least the filter_classes tool (H-165) generates the following list: cat missing_classes.txt javax/xml/parsers/SAXParserFactory javax/xml/parsers/ParserConfigurationException javax/xml/parsers/DocumentBuilderFactory javax/xml/parsers/DocumentBuilder javax/xml/parsers/SAXParser javax/xml/transform/Source javax/xml/transform/Result javax/xml/transform/TransformerException javax/xml/transform/TransformerConfigurationException org/w3c/dom/Node org/w3c/dom/NodeList org/w3c/dom/Document org/w3c/dom/Element org/w3c/dom/TypeInfo org/w3c/dom/CharacterData org/w3c/dom/Comment org/w3c/dom/DocumentType org/w3c/dom/NamedNodeMap org/w3c/dom/Attr org/w3c/dom/Text org/w3c/dom/events/EventTarget org/w3c/dom/events/DocumentEvent org/xml/sax/AttributeList org/xml/sax/EntityResolver org/xml/sax/InputSource org/xml/sax/SAXException org/xml/sax/DTDHandler org/xml/sax/ContentHandler org/xml/sax/ErrorHandler org/xml/sax/Parser org/xml/sax/XMLReader org/xml/sax/Attributes org/xml/sax/Locator org/xml/sax/ext/EntityResolver2 org/xml/sax/ext/Attributes2 org/xml/sax/ext/Locator2 org/xml/sax/helpers/DefaultHandler org/xml/sax/helpers/AttributesImpl Thanks, Vladimir. I will take a look at the Linux crash next and see if I can get anywhere with that. Ill add the above stack trace to the JIRA. Regards, Oli [1] http://incubator.apache.org/harmony/roadmap.html Vladimir Gorr wrote: ArgoUML application (http://argouml.tigris.org) crashes IBM VME. I've created new issue (H-1257) where the logs are. Could anybody please look at this problem and fix it? Thanks, Vladimir. -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm] ArgoUML application crashes IBM VME
Ok, thanks for this reminder. I've absolutely forgot about this property. I'll try to re-build. My next question is why this property is not set by default? Are there any obstacles for this? Thanks, Vladimir. On 8/23/06, Ilya Okomin [EMAIL PROTECTED] wrote: Hello, Vladimir! I've took a look at the issue you've mentioned.On Windows platform WinGraphicsEnvironment couldn't load 'gl' library. Make sure you have built native awt/swing libraries (build Harmony with ' with.awt.swing' property set to true). Thanks, Ilya. On 8/23/06, Vladimir Gorr [EMAIL PROTECTED] wrote: ArgoUML application (http://argouml.tigris.org) crashes IBM VME. I've created new issue (H-1257) where the logs are. Could anybody please look at this problem and fix it? Thanks, Vladimir. -- -- Ilya Okomin Intel Middleware Products Division
Re: [vm] ArgoUML application crashes IBM VME
On 8/23/06, Mark Hindess [EMAIL PROTECTED] wrote: On 23 August 2006 at 16:03, Vladimir Gorr [EMAIL PROTECTED] wrote: Ok, thanks for this reminder. I've absolutely forgot about this property. I'll try to re-build. My next question is why this property is not set by default? Are there any obstacles for this? Some way to (automatically) satisfy the dependencies in depends/libs/build/README.txt. I made a vague attempt to do something on linux (which I expected people to add to for other distributions but it seems everyone uses Debian variants?). I think someone was looking at the windows case but I've not seen any progress recently. It looked to me like it was heading towards a solution that downloaded and built the sources to get usable dll's for windows. Thanks, Mark, for this clarification. Vladimir. Regards, Mark. On 8/23/06, Ilya Okomin [EMAIL PROTECTED] wrote: Hello, Vladimir! I've took a look at the issue you've mentioned.On Windows platform WinGraphicsEnvironment couldn't load 'gl' library. Make sure you have built native awt/swing libraries (build Harmony with ' with.awt.swing' property set to true). Thanks, Ilya. On 8/23/06, Vladimir Gorr [EMAIL PROTECTED] wrote: ArgoUML application (http://argouml.tigris.org) crashes IBM VME. I've created new issue (H-1257) where the logs are. Could anybody please look at this problem and fix it? Thanks, Vladimir. -- -- Ilya Okomin Intel Middleware Products Division --=_Part_132741_26056656.1156323829512-- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vm] ArgoUML application crashes IBM VME
ArgoUML application (http://argouml.tigris.org) crashes IBM VME. I've created new issue (H-1257) where the logs are. Could anybody please look at this problem and fix it? Thanks, Vladimir.
Re: [general] Classlib updated to 5.0 builds - new IBM VME required
On 8/8/06, Oliver Deakin [EMAIL PROTECTED] wrote: Tim Ellison wrote: I've just committed the HARMONY-1084 patch (thanks Oliver) at repository revision r429714 that brings the class library code building up to 5.0. The jsr-14 target is now gone! cheers and applause at disappearance of jsr14 There is one module (rmi2) that uses this property yet. So it's prematurely to applaud :-). Thanks, Vladimir. Reports are that this code works with the latest version of DRLVM without further modification. If you want to run/test with the IBM VME you have to move up to version 4 which is available here [1]. If you had the previous VME version and want to continue using the new one, you will just have to: - update your classlib checkout to get the H-1084 patch - rebuild classlib with ant rebuild - completely delete the old VME (in deploy/jdk/jre/bin/default) - unpack the new VME under the deploy/jdk directory (it has a jre shape) From there you should be able to continue developing/testing as before. If you hit any problems, please post here and we'll all try to figure it out :) Regards, Oliver Regards, Tim [1] http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][CORBA] Apache Yoko integration
On 8/3/06, Tim Ellison [EMAIL PROTECTED] wrote: Alexey Petrenko wrote: 2006/8/3, Geir Magnusson Jr [EMAIL PROTECTED]: Alexey Petrenko wrote: 2006/8/3, Geir Magnusson Jr [EMAIL PROTECTED]: Alexey Petrenko wrote: Yes, it is possible to build one exact Yoko module with the self-made build script with just Harmony, Ant and Eclipse compiler. really? Are you saying that you can build the yoko we need w/ your build script? Or just one part of it? Yep, I've made a small ant script just to run Eclipse compiler Do you think you could show it to us? :) I think yes :) It's just 5-lines script which is running javac... Nothing special. Better still, show it to the Yoko dev's -- if it really is that short then perhaps their build scripts would benefit from such simplification! Indeed, if the simplest script is used instead of the original build system it'd be not bad to discuss it with the Yoko team. We need to make sure we get the working version as a result. Is there any test suite we could use for this purpose? Thanks, Vladimir. Regards, Tim But if you want to build Yoko using its usual build process then you need Maven and Maven will download 64Mb of dependencies. We can extend Harmony build script to build Yoko from sources. That's one of the possible solutions. But we will need to update the script each time something changes in Yoko... But it is possible. I think just having a jar in SVN for now until the release comes will work. Thanks for doing this. geir SY, Alexey 2006/8/3, Mikhail Loenko [EMAIL PROTECTED]: Alexey sorry I'm not a Yoko expert, but what are the huge number of dependencies that are necessary to build Yoko? As you mentioned you've built it with Eclipse and Harmony Thanks, Mikhail 2006/8/3, Alexey Petrenko [EMAIL PROTECTED]: BTW, I've built Yoko sources using Harmony, Ant and Eclipse compiler without errors. So it seems that Harmony has all the methods required by Yoko. At least declare them :) SY, Alexey 2006/8/3, Alexey Petrenko [EMAIL PROTECTED]: Guys, I've created JIRA issue 1056 [1] to integrate Apache Yoko [2] to Harmony as CORBA implementation. Since Yoko does not have official releases yet I suggest to put yoko.jar to Harmony svn tree. Any objections? SY, Alexey [1] http://issues.apache.org/jira/browse/HARMONY-1056 [2] Apache Yoko - http://incubator.apache.org/yoko/ -- Alexey A. Petrenko Intel Middleware Products Division -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [vote] accept HARMONY-935 as our implementation of math
+1 I'm glad it happened. For now this package will contain all the best from two previous contributions for java.math. Thanks, Vladimir. On 8/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: +1 (note, this is a vote by lazy consensus... we'll let it go a day or two and then keep moving...) Geir Magnusson Jr wrote: https://issues.apache.org/jira/browse/HARMONY-935 I figure we should make it a clear vote thread so people don't miss it. Lots of great work has been done on this subject by many people showing great community spirit, collaboration and teamwork, and it's time to bring it to closure. There has been much discussion, but the relevant thread to peruse has the subject : [classlib][java.math] combination of math packages [ ] +1 Accept Harmony-935 as Harmony's math implementation [ ] 0 No opinion [ ] -1 Against accepting Harmony-935 as Harmony's math implementation 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: some question about drlvm
Hi Zou, I asked you to clarify what do your files for the H-992 issue mean? Could you please answer me? Thanks, Vladimir. On 7/28/06, zouqiong [EMAIL PROTECTED] wrote: I rerun the application with option -Xint and unlucily, it doesn`t pass, keep running and nothing comes out. The same with other options except with option -Xem opt. with option -Xem opt, many SIGSEGV in VM code. are printed. 28 Jul 2006 17:05:44 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1B3 day of Apache Harmony [EMAIL PROTECTED] wrote: I rerun it, and it keeps running, however no result comes out. or I upload the jar file in two packages. OK, we can investigate the problem directly on your machine. There are some basic steps I do as soon as I see some problem :) * option to run in *interpreter mode*: -Xint If it passes, we can suspect a JIT. Then, no matter of results, it makes sense to isolate a single JIT to figure out which JIT is more unhealthy on your problem. * option to run on *fast JIT* only: -Xem jet * Run on *optimizing JIT* only: -Xem opt if you find where the problem appears more precisely, we can investigate further (with help of more extra options) 2006/7/27, Vladimir Gorr [EMAIL PROTECTED]: Could you please run your application as the following: export LD_LIBRARY_PATH=/home/ustczz/harmony/enhanced/drlvm/trunk/build/deploy/jre/bin; /home/ustczz/harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java.exe -jar EIOffice.jar And let me know about the results. Thanks, Vladimir. On 7/27/06, zouqiong [EMAIL PROTECTED] wrote: i download my java application on the web, and it`s open source. But i can`t upload it with jira, because the running of the jar file depend other files, and the size of all source is above 300M, and at most it can be compressed to 60M. This is the link i download the source http://dlc2.pconline.com.cn/filedown.jsp?dlid=8242linkid=27642 however, the application is developed by a Chinese group, it may bring you some difficulty. 2006/7/27, Vladimir Gorr [EMAIL PROTECTED]: On 7/27/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, besides the mbox size, please also note the license issue before you forward your EIOffice.jar. :-) Yes, this is important note. I've also thought about this. (Probably you can give a link of the original downloaded site. I don't know.) Yes, if its license allows to make this :-). Thanks, Vladimir. Thanks, xiaofeng On 7/27/06, zouqiong [EMAIL PROTECTED] wrote: Hi, Sir, I am afraid, i can`t attach the java application with gmail, maybe it`s too large?? Its size is 24M, within the 1G of gmail, isn`t it? Is there other ways i can attach my jar files? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards, Qiong,Zou
Re: [vote] acceptance of HARMONY-856 : assorted bug fixed for DRLVM
Probably, Mikhail meant *+2* because I've already saw his vote two days ago J. As for me +1. Thanks, Vladimir. On 7/27/06, Mikhail Loenko [EMAIL PROTECTED] wrote: +1 2006/7/26, Stepan Mishura [EMAIL PROTECTED]: +1 -Stepan. On 7/24/06, Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-856 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 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: some question about drlvm
On 7/27/06, zouqiong [EMAIL PROTECTED] wrote: en, i create the new issue , the link is : https://issues.apache.org/jira/browse/HARMONY-992 and please read my comment for the file. And i hope this would help. It would not, unfortunately. Any instructions, please, how I can get your jar file (*EIOffice.jar*) from these attachments. Or explain what do these files mean? Friendly advice is to add in future some attendant comments for the convenience of other stakeholders. Thanks, Vladimir. Best Regard
Re: some question about drlvm
Hi Zouqiong, it's fine almost all problems have been resolved on your side. Could you please create new Jira issue and attach your jar file here? This needs us to reproduce your issue on our side if any. Thanks, Vladimir. On 7/27/06, zouqiong [EMAIL PROTECTED] wrote: i solve the problem if i used the jdk1.5 platfrom: fc5, gcc-3.4.6, jdk1.5 and i find that the java replaced ij.. :-) and i use the new java to compile my application, however new problem encounters, there is no error information comes out, it seems that it has stopped to compile the application, but still running. so i use gdb to trace it, and i use bt commond, you can see the stack. (gdb) run -jar EIOffice.jar Starting program: /home/ustczz/harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java.exec -jar EIOffice.jar Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x988000 [Thread debugging using libthread_db enabled] [New Thread -1208674624 (LWP 3512)] [New Thread 76307360 (LWP 3515)] [New Thread 31476640 (LWP 3516)] [New Thread 52206496 (LWP 3519)] [New Thread 87272352 (LWP 3520)] [New Thread 97762208 (LWP 3521)] [New Thread 115604384 (LWP 3524)] [Thread 115604384 (LWP 3524) exited] [New Thread 115604384 (LWP 3525)] [New Thread 134413216 (LWP 3526)] [Thread 115604384 (LWP 3525) exited] [Thread 87272352 (LWP 3520) exited] Program received signal SIGINT, Interrupt. [Switching to Thread -1208674624 (LWP 3512)] 0x00988402 in __kernel_vsyscall () (gdb) ps ax Undefined command: ps. Try help. (gdb) bt #0 0x00988402 in __kernel_vsyscall () #1 0x0024f48c in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x001d5098 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libc.so.6 #3 0x00f6df0a in vm_wait_for_single_object (hHandle=140436112, dwMillisec=2000) at /home/ustczz/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/linux/os_wrapper.cpp:285 #4 0x00f7f8f8 in wait_until_non_daemon_threads_are_dead () at /home/ustczz/harmony/enhanced/drlvm/trunk/vm/vmcore/src/thread/thread_generic.cpp:918 #5 0x00f04207 in Java_java_lang_VMStart_joinAllNonDaemonThreads (jenv=0x113b0f0, starter=0xbfa70bf4) at /home/ustczz/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/native/java_lang_VMStart.cpp:29 #6 0x002b7da0 in ?? () #7 0x0113b0f0 in java_vm () from /home/ustczz/harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libvmcore.so #8 0xbfa70bf4 in ?? () #9 0x00010009 in ?? () #10 0x in ?? () I hope the trace can help to find the problem, and thank you for solving it :-)
Re: [drlvm] uses deprecated pthread function
I have same issue for FC5. The patch for H-977 helps to resolve it. Therefore it'd be not bad to apply this patch to SVN repository for convenience. Thanks, Vladimir. On 7/26/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Wednesday 26 July 2006 01:18 Geir Magnusson Jr wrote: Gregory Shimansky wrote: Hello I've tried to build drlvm on Linux and it didn't compile because when compiling signals_ia32.cpp file compiler produced a warning that pthread_attr_getstackaddr is deprecated. I looked in /usr/include/pthread.h [1] and found out that it is really deprecated by __attribute_deprecated__. I don't know why everything is fine for others but for me gcc [2] does gives a warning on this function. I used the recommended replacement pthread_attr_getstack which gives both address and stack size in one call. The patch is in HARMONY-977. StackTest and other vm smoke tests pass for me now. Weird. It always has built for me on ubuntu 5/6 and passed the smoke tests. Is it marked as deprecated in your /usr/include/pthread.h header too? I googled a bit and found some references to Debian and Fedora that pthread_attr_getstackaddr is deprecated. There are even a bugs on Sun JDK about it [1]. Maybe this change just didn't make it into Ubuntu yet. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6349489 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6339849 -- 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][classlib] unification of eclipse plugin
On 7/22/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm going to punt here so I can move on. I'll make a copy of the plugin code in DRLVM, and apply the patch, so we All you're going (if I've correctly understood) to is automatically performed by the DRLVM build system. All we need is to remove the VM specific code from the Eclipse launcher to use it by any of VMs. In this case there are no needs to have this patch and we'll remove it. Are you agree with such approach? Thanks, Vladimir. then have a plugin appropriate to the non-launcher DRLVM for the hopefully short time that persists. Once we get the DRLVM + launcher stuff straightened out, we'll just remove it. geir Alexey Petrenko wrote: 2006/7/21, Vladimir Gorr [EMAIL PROTECTED]: On 7/21/06, Alexey Petrenko [EMAIL PROTECTED] wrote: AFAIR, the one is the main hacks is the list of jar files in boot class path... There are no problems with this. DRLVM contains the bootclasspath.propertiesfile where all these libraries are listed. This one is deployed to the lib/boot directory. I know this :) But I mean that plugin defines boot class path jars list for the Eclipse. Eclipse shows them in the corresponding dialogs... As far as I remember... 2006/7/21, Geir Magnusson Jr [EMAIL PROTECTED]: Part of the original DRLM contribution is a patch for the eclipse plugin. When I shifted DRLVM to produce java rather than ij as the program name, much of the patch went away. However, there is still some that I honestly didn't understand, as it seems like were working in and around a bunch of hacks. I'm happy to spend the time and really figure it out, but there's enough people around here who grok eclipse well enough to tell me if I can integrate the remaining changes and get this done. So please? Help? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] trouble invoking build from 'afar'
Yes, I'm in progress already. Thanks, Vladimir. On 7/21/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Yep, it looks like an ant bug. I've searched ant bug database and have not find any open bugs according this issue. So we probably should file it. SY, Alexey 2006/7/20, Vladimir Gorr [EMAIL PROTECTED]: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ [SNIP] The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks. That works. I don't understand why ant dir=trunk inheritall=false target=build/ doesn't. It seems this is new bug if I correctly undrstand the ant sub-task documentation: *When the antfile attribute is omitted, the file build.xml in the supplied directory (dir attribute) is used.* Thanks, Vladimir. I thought when I saw your answer the real problem was that I didn't use 'inheritall=false', but that's not the case. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trouble invoking build from 'afar'
New ant bug has been created for this issue: *http://issues.apache.org/bugzilla/show_bug.cgi?id=40088*http://issues.apache.org/bugzilla/show_bug.cgi?id=40088 Thanks, Vladimir. On 7/21/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Ok, great. 2006/7/21, Vladimir Gorr [EMAIL PROTECTED]: Yes, I'm in progress already. Thanks, Vladimir. On 7/21/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Yep, it looks like an ant bug. I've searched ant bug database and have not find any open bugs according this issue. So we probably should file it. SY, Alexey 2006/7/20, Vladimir Gorr [EMAIL PROTECTED]: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ [SNIP] The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks. That works. I don't understand why ant dir=trunk inheritall=false target=build/ doesn't. It seems this is new bug if I correctly undrstand the ant sub-task documentation: *When the antfile attribute is omitted, the file build.xml in the supplied directory (dir attribute) is used.* Thanks, Vladimir. I thought when I saw your answer the real problem was that I didn't use 'inheritall=false', but that's not the case. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] hdk and jre for review...
On 7/21/06, Tim Ellison [EMAIL PROTECTED] wrote: I downloaded and tried it out on Windows... Comments on packaging/layout: As pointed out by Nathan, the JRE seems to have way more in it than we actually need. In jre/bin: - What happened to the harmony launcher and the ability to use different VMs? I'm concerned that having a DRLVM-specific launcher, and putting all the DRLVM files directly into jre/bin breaks the goal to run with multiple VMs. - I'm assuming that the slam of the hythr library is a temporary solution while we continue the discussion? - There seems to be a spurious Hello.class and encoder.lib in there. Elsewhere: - jre/lib is a strange place to put the Eclipse plug-in support. I don;t think this should be in the HDK/JRE at all as it is a separate piece of work. - Should not be a jdk/jre/include directory, only the jdk/include. We have two different copies of jni.h. Running code: - The batch file was not much use to me... C:\download\rssowl_1_2_1_win32_bin\temp\harmony-hdk-r424020\jdk\jre\bin\java.bat -jar rssowl.jar C:\download\rssowl_1_2_1_win32_bin.\java.exe -jar rssowl.jar '.\java.exe' is not recognized as an internal or external command, operable program or batch file. but the .exe ran ok and RSSOwl seems to work just fine. I had the same problem as Nathan (ERROR: Destructive unwinding: C++ objects detected on stack!) when trying to run Eclipse 3.2. Once more: http://issues.apache.org/jira/browse/HARMONY-939 should eliminate this issue. Thanks, Vladimir. Regards, Tim Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony (I'm still battling windows...) The VM was built in release mode, and I have to say, it's not too shabby! If no one has any objections or showstoppers, I'd like to post both linux and win to our snapshot download site. As this is a snapshot, I'm looking for a basic smoketest or pointing any stupidity or gross mistakes I may have made. If not, I'd like to go forward, and just iterate. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] unification of eclipse plugin
Indeed we need to re-base the plugin patch for DRLVM due to the recent changes (renaming ij to java). However all 'hacks' cannot be removed due to the original sources of plugin refer to the clearvm library DRLVM doesn't suppose to have. We will post these change a little later (we need to make sure all works). Is next Monday suitable for you? Thanks, Vladimir. On 7/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Part of the original DRLM contribution is a patch for the eclipse plugin. When I shifted DRLVM to produce java rather than ij as the program name, much of the patch went away. However, there is still some that I honestly didn't understand, as it seems like were working in and around a bunch of hacks. I'm happy to spend the time and really figure it out, but there's enough people around here who grok eclipse well enough to tell me if I can integrate the remaining changes and get this done. So please? Help? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] unification of eclipse plugin
On 7/21/06, Alexey Petrenko [EMAIL PROTECTED] wrote: AFAIR, the one is the main hacks is the list of jar files in boot class path... There are no problems with this. DRLVM contains the bootclasspath.propertiesfile where all these libraries are listed. This one is deployed to the lib/boot directory. Thanks, Vladimir. 2006/7/21, Geir Magnusson Jr [EMAIL PROTECTED]: Part of the original DRLM contribution is a patch for the eclipse plugin. When I shifted DRLVM to produce java rather than ij as the program name, much of the patch went away. However, there is still some that I honestly didn't understand, as it seems like were working in and around a bunch of hacks. I'm happy to spend the time and really figure it out, but there's enough people around here who grok eclipse well enough to tell me if I can integrate the remaining changes and get this done. So please? Help? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] unification of eclipse plugin
On 7/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: Indeed we need to re-base the plugin patch for DRLVM due to the recent changes (renaming ij to java). However all 'hacks' cannot be removed due to the original sources of plugin refer to the clearvm library DRLVM doesn't suppose to have. We will post these change a little later (we need to make sure all works). Is next Monday suitable for you? I don't need a patch (I can figure out the ij-java issues - select with mouse, cut, save) as much as some understanding that the whole 'clearvm' thing and the hacks around it are not harmful. Clearly this isn't optimal, and will need to be refactored, but I just want someone who knows eclipse and J9 (hint, Tim, hint) to say sure, go for it This patch can be removed after the eclipse plugin sources will be tuned accordingly. Otherwise the replacement of ij with java will not help if I correctly understand your intention. Thanks, Vladimir. geir Thanks, Vladimir. On 7/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Part of the original DRLM contribution is a patch for the eclipse plugin. When I shifted DRLVM to produce java rather than ij as the program name, much of the patch went away. However, there is still some that I honestly didn't understand, as it seems like were working in and around a bunch of hacks. I'm happy to spend the time and really figure it out, but there's enough people around here who grok eclipse well enough to tell me if I can integrate the remaining changes and get this done. So please? Help? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trouble invoking build from 'afar'
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ To demonstrate, go to enhanced/classlib and run the following ant script : ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. target name=default ant dir=trunk/ /target /project It bombs because there is some confusion about basedir or something : C:\dev\apache\harmony\enhanced\classlib\trunk\modules\accessibility\build.xml:23: Cannot find C:\dev\apache\harmony\enhanced\classlib\trunk/../../make/properties.xml imported from C:\dev\apache\harmony\enhanced\classlib\trunk\modules\access ibility\build.xml I'll dig into this in the morning, but if any of you ant gurus could propose a fix... The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
The issue mentioned below disapperead after the latest changes for class library. Nevertheless I'm not clear a clue for this build error. In any case thanks for this fix. Vladimir. On 7/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto: [EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - 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] trouble invoking build from 'afar'
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ [SNIP] The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks. That works. I don't understand why ant dir=trunk inheritall=false target=build/ doesn't. It seems this is new bug if I correctly undrstand the ant sub-task documentation: *When the antfile attribute is omitted, the file build.xml in the supplied directory (dir attribute) is used.* Thanks, Vladimir. I thought when I saw your answer the real problem was that I didn't use 'inheritall=false', but that's not the case. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - 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:
Re: [drlvm] Status of drlvm
Probably I've understood the reason of the segmentation fault on Linux platform. I almost sure it is related with the build system. An argument why I think so is the following. The basic_istringstream() class from the /usr/include/g++/sstream include should be used to construct the configuration environment for the execution manager (vm/em/src/DrlEMIml.cpp file). However the recent build uses this class from the /usr/lib/libstdc++.so.5 library instead and as a result DRLVM fails. I'm going to continue this investigation and prepare a patch to fix this issue if someone doesn't already know how. Volunteers? Thanks, Vladimir. On 7/18/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 7/17/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? I've built the DRLVM on Linux for the following cases: 1. w/o patches listed above; 2. w/ H-898 patch; 3. w/ H-898 H-853 patches. 'Segmentation fault' occurs for all cases, unfortunately. I was able to run most of smoke tests on Linux a few days ago, but now I'm having the same segfault failure. Some observations are: - In the interpreted mode (-Xint option) it reports ClassNotFoundException, so it seems VM can no longer load the classes from jars on Linux. I was able to run a single Hello class though. - Segfault actually happens during VM shutdown, after the main() is already completed with CNFE error. I wasn't able to find the exact point of segfault though - it seems it happens somewhere in a jitted code, gdb doesn't show a much of useful info in that case: #0 0x40788aa2 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0010 in ?? () #2 0x4083c7c8 in main_arena () from /lib/tls/libc.so.6 #3 0x in ?? () #4 0x4083c7b4 in main_arena () from /lib/tls/libc.so.6 #5 0x4083c798 in main_arena () from /lib/tls/libc.so.6 #6 0x4083c780 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #7 0x4083aff4 in ?? () from /lib/tls/libc.so.6 #8 0x0855cdd0 in ?? () #9 0x00037230 in ?? () #10 0x56500158 in ?? () #11 0x40789bf6 in _int_free () from /lib/tls/libc.so.6 Previous frame inner to this frame (corrupt stack?) I'm continuing investigation, the same behavior is observed on Linux if run with classlib's launcher. Thanks, Andrey. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrey Chernyshev 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] Status of drlvm
Ignore please my previous e-mail. I was slightly mistaken :-(. Thanks, Vladimir. On 7/18/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Probably I've understood the reason of the segmentation fault on Linux platform. I almost sure it is related with the build system. An argument why I think so is the following. The basic_istringstream() class from the /usr/include/g++/sstream include should be used to construct the configuration environment for the execution manager (vm/em/src/DrlEMIml.cpp file). However the recent build uses this class from the /usr/lib/libstdc++.so.5 library instead and as a result DRLVM fails. I'm going to continue this investigation and prepare a patch to fix this issue if someone doesn't already know how. Volunteers? Thanks, Vladimir. On 7/18/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 7/17/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? I've built the DRLVM on Linux for the following cases: 1. w/o patches listed above; 2. w/ H-898 patch; 3. w/ H-898 H-853 patches. 'Segmentation fault' occurs for all cases, unfortunately. I was able to run most of smoke tests on Linux a few days ago, but now I'm having the same segfault failure. Some observations are: - In the interpreted mode (-Xint option) it reports ClassNotFoundException, so it seems VM can no longer load the classes from jars on Linux. I was able to run a single Hello class though. - Segfault actually happens during VM shutdown, after the main() is already completed with CNFE error. I wasn't able to find the exact point of segfault though - it seems it happens somewhere in a jitted code, gdb doesn't show a much of useful info in that case: #0 0x40788aa2 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0010 in ?? () #2 0x4083c7c8 in main_arena () from /lib/tls/libc.so.6 #3 0x in ?? () #4 0x4083c7b4 in main_arena () from /lib/tls/libc.so.6 #5 0x4083c798 in main_arena () from /lib/tls/libc.so.6 #6 0x4083c780 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #7 0x4083aff4 in ?? () from /lib/tls/libc.so.6 #8 0x0855cdd0 in ?? () #9 0x00037230 in ?? () #10 0x56500158 in ?? () #11 0x40789bf6 in _int_free () from /lib/tls/libc.so.6 Previous frame inner to this frame (corrupt stack?) I'm continuing investigation, the same behavior is observed on Linux if run with classlib's launcher. Thanks, Andrey. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrey Chernyshev 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] Status of drlvm
The reason of the 'seg fault' issue is clear for me now. I see this issue occurs when I used the gcc of 3.4.2 version. All works fine for the *gcc (GCC) 3.3.3 (SuSE Linux).* Could anybody else confirm or deny this? Thanks in advance, Vladimir. On 7/18/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Ignore please my previous e-mail. I was slightly mistaken :-(. Thanks, Vladimir. On 7/18/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Probably I've understood the reason of the segmentation fault on Linux platform. I almost sure it is related with the build system. An argument why I think so is the following. The basic_istringstream() class from the /usr/include/g++/sstream include should be used to construct the configuration environment for the execution manager (vm/em/src/DrlEMIml.cpp file). However the recent build uses this class from the /usr/lib/libstdc++.so.5 library instead and as a result DRLVM fails. I'm going to continue this investigation and prepare a patch to fix this issue if someone doesn't already know how. Volunteers? Thanks, Vladimir. On 7/18/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 7/17/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? I've built the DRLVM on Linux for the following cases: 1. w/o patches listed above; 2. w/ H-898 patch; 3. w/ H-898 H-853 patches. 'Segmentation fault' occurs for all cases, unfortunately. I was able to run most of smoke tests on Linux a few days ago, but now I'm having the same segfault failure. Some observations are: - In the interpreted mode (-Xint option) it reports ClassNotFoundException, so it seems VM can no longer load the classes from jars on Linux. I was able to run a single Hello class though. - Segfault actually happens during VM shutdown, after the main() is already completed with CNFE error. I wasn't able to find the exact point of segfault though - it seems it happens somewhere in a jitted code, gdb doesn't show a much of useful info in that case: #0 0x40788aa2 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0010 in ?? () #2 0x4083c7c8 in main_arena () from /lib/tls/libc.so.6 #3 0x in ?? () #4 0x4083c7b4 in main_arena () from /lib/tls/libc.so.6 #5 0x4083c798 in main_arena () from /lib/tls/libc.so.6 #6 0x4083c780 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #7 0x4083aff4 in ?? () from /lib/tls/libc.so.6 #8 0x0855cdd0 in ?? () #9 0x00037230 in ?? () #10 0x56500158 in ?? () #11 0x40789bf6 in _int_free () from /lib/tls/libc.so.6 Previous frame inner to this frame (corrupt stack?) I'm continuing investigation, the same behavior is observed on Linux if run with classlib's launcher. Thanks, Andrey. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrey Chernyshev 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] Status of drlvm
Nataly, I believe you need to accept both patches mentioned by Silikh in the initial e-mail of this thread, namely, H-898 H-853. Could you please check if the 'seg fault' issue disappears for gcc 3.3.4 as well? Thanks, Vladimir. On 7/18/06, Nataly Naumova [EMAIL PROTECTED] wrote: Vladimir and all, I've compiled with gcc 3.3.4 and received `seg faults` since July,08 till now. I'm not applying any patches, and take just *pure* drlvm from SVN. DRLVM build for July,05 is fine, then the build was broken (on linux). Maybe we should look through the commits since July,05 till July 08 ? There were not too many commits there. Thanks. -- Nataly Naumova, Intel Middleware Products Division On 7/18/06, Vladimir Gorr [EMAIL PROTECTED] wrote: The reason of the 'seg fault' issue is clear for me now. I see this issue occurs when I used the gcc of 3.4.2 version. All works fine for the *gcc (GCC) 3.3.3 (SuSE Linux).* Could anybody else confirm or deny this? Thanks in advance, Vladimir. On 7/18/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Ignore please my previous e-mail. I was slightly mistaken :-(. Thanks, Vladimir. On 7/18/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Probably I've understood the reason of the segmentation fault on Linux platform. I almost sure it is related with the build system. An argument why I think so is the following. The basic_istringstream() class from the /usr/include/g++/sstream include should be used to construct the configuration environment for the execution manager (vm/em/src/DrlEMIml.cpp file). However the recent build uses this class from the /usr/lib/libstdc++.so.5 library instead and as a result DRLVM fails. I'm going to continue this investigation and prepare a patch to fix this issue if someone doesn't already know how. Volunteers? Thanks, Vladimir. On 7/18/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 7/17/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? I've built the DRLVM on Linux for the following cases: 1. w/o patches listed above; 2. w/ H-898 patch; 3. w/ H-898 H-853 patches. 'Segmentation fault' occurs for all cases, unfortunately. I was able to run most of smoke tests on Linux a few days ago, but now I'm having the same segfault failure. Some observations are: - In the interpreted mode (-Xint option) it reports ClassNotFoundException, so it seems VM can no longer load the classes from jars on Linux. I was able to run a single Hello class though. - Segfault actually happens during VM shutdown, after the main() is already completed with CNFE error. I wasn't able to find the exact point of segfault though - it seems it happens somewhere in a jitted code, gdb doesn't show a much of useful info in that case: #0 0x40788aa2 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0010 in ?? () #2 0x4083c7c8 in main_arena () from /lib/tls/libc.so.6 #3 0x in ?? () #4 0x4083c7b4 in main_arena () from /lib/tls/libc.so.6 #5 0x4083c798 in main_arena () from /lib/tls/libc.so.6 #6 0x4083c780 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #7 0x4083aff4 in ?? () from /lib/tls/libc.so.6 #8 0x0855cdd0 in ?? () #9 0x00037230 in ?? () #10 0x56500158 in ?? () #11 0x40789bf6 in _int_free () from /lib/tls/libc.so.6 Previous frame inner to this frame (corrupt stack?) I'm continuing investigation, the same behavior is observed on Linux if run with classlib's launcher. Thanks, Andrey. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrey Chernyshev Intel Middleware Products Division
Re: [drlvm] Status of drlvm
On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? I've built the DRLVM on Linux for the following cases: 1. w/o patches listed above; 2. w/ H-898 patch; 3. w/ H-898 H-853 patches. 'Segmentation fault' occurs for all cases, unfortunately. Thanks, Vladimir. - 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] compatibility nuances
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds like all
is
correct.
Right, from the spec point of view everything is correct. But I'd
like to say that our particular order differs from RI particular
order
(and such behavior conforms to spec). My next statement is: there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that since
we
are free to do what we want, and if someone does depende on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter, JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have. Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
On 7/13/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi Vladimir, Where exceptions should be thrown is a big question in this thread. Native code or Java code or mixed? Yes, I'm aware about this. However I'd prefer to have other subject for this thread :-). Thanks, Vladimir. Shall we avoid throwing all exceptions in Harmony native code? If all exceptions are thrown in java code, there is no need to involve any other I18N utilities (i.e. log4cXXX). Really appreciated if anyone could summarize the advantages and disadvantages of these two exeption-thrown ways (by native or java). Thanks! On 7/13/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Indeed we need to i18d the native code to resolve this issue. I'd suggest to use the log4cxx resource bundle approach for doing this. This one can be suitable for both VMs API natives. I'm going to create new thread to discuss this approach. Thanks, Vladimir. Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
[drlvm] proposals for VM internationalization
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all. However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage, logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and LANG.
Chosen ResourceBundles should be used for printing localized messages from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be empty.
_country is a country e.g. _RU (Russian federation ). It may be empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English) should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of vm's
subcomponent name ( e.g. init, port, gc.) and short description of message.
E.g. init.help is localized help message from init subcomponent of VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message pattern:
This is message on English with two parameters: parameter number one – {0},
and parameter number two – {1}. We can print it again and in back order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above should
be:
This is message on English with two parameters: parameter number one – 1,
and parameter number two – two. We can print it again and in back order:
two, 1.
* *
*4. Requirements. *
- All localized messages may be printed through apache log4cxx logger.
- Parameters may be present in localized messages.
- VM-I18N subsystem should automatically detect user's locale
according to values of environment variables.
- Minimize performance impact.
Re: [drlvm] proposals for VM internationalization
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
layout
And if we talk about ResourceBundle only, I'd suggest consider ICU4C as
a candidate, which provides many i18n features including
ResourceBundle[1] support to c as well as c++, and more important, it
has been included as Harmony dependencies.
Of course, if you think VM needs more complicated log mechanism support,
this will be another story.
Yes, this is such case. I suppose some of us will want to read the debug
output from JIT
in the Chinese language. Why not? However you're right the ICU4C can be also
used for some cases.
Maybe it makes sense to combine these two mechanisms (one for user messages,
other for internal needs).
Just the log4cxx is used as logging system for DRLVM and we think a little
of efforts will need to internationalize
the native code in this case.
Thanks,
Vladimir.
[1]http://icu.sourceforge.net/apiref/icu4c/
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all.
However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide
localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which
allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized
messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage, logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and
LANG.
Chosen ResourceBundles should be used for printing localized messages
from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the
following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be
empty.
_country is a country e.g. _RU (Russian federation ). It may be
empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English)
should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development
guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of
vm's
subcomponent name ( e.g. init, port, gc.) and short description of
message.
E.g. init.help is localized help message from init subcomponent of
VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message
pattern:
This is message on English with two parameters: parameter number one
– {0},
and parameter number two – {1}. We can print it again and in back order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above
should
be:
This is message on English with two parameters: parameter number one
– 1,
and parameter number two – two. We can print it again and in back order:
two, 1.
* *
*4. Requirements. *
- All localized messages may be printed through apache log4cxx logger.
- Parameters may be present in localized messages.
- VM-I18N subsystem should automatically detect user's locale
according to values of environment variables.
- Minimize performance impact.
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use
Re: [drlvm] proposals for VM internationalization
In my opinion using the gettext() for the i18n goals will involve too big
re-factoring of source code.
I also disagree with the 'no-meaning' for message key. All we need is to
create the sensible ID for these messages.
*4) Add to this that most of the developers will not know where the
localized messages are kept,
and you'll get the situation when most of the messages are not localized in
any way.
*
I'm not sure the gettext() will eliminate this issue.
Thanks,
Vladimir.
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
Internationalization design *1. Introduction*
...
The key idea is to use ResourceBundle class from apache log4cxx which
allow
to store and effective use bundles with localized messages.
Why not use GNU gettext -- de facto standard i18n system on GNU/Linux
systems?
I think the developers' API can be a designed to allow a wide range of
i18n implementations, just like we did with logging.
(* DRLVM logging system was designed in such a way, that its
implementation
could be rewritten completely from scratch. It was in fact rewritten
once
to use log4cxx. No client code modifications were required *)
I think we could devise a simple localization API, which even could be
dummy
to get us started, like
8- vm/include/l10n.h
#define _(x) (x)
inline void init_l10n() {}
---
Scan over the DRLVM code, mark the translatable strings with _(),
and then evolve the l10n system independently of the development efforts.
MessageId1=localized message1
MessageId2=localized message2
Where:
MessageId{i} �C ASCII string on English language. It should consist of
vm's
subcomponent name ( e.g. init, port, gc.) and short description of
message.
E.g. init.help is localized help message from init subcomponent of
VM.
The gettext has an advantage, that the unlocalized messages are used as
the
keys for the translation, thus, the developers do not need to care about
l10n at all.
On the other hand, in the system you propose, to create a message,
one will need to
1) come up with the message identifier
2) add the message identifier and it's unlocalized text to the resource
file
and, most annoyingly,
3) consult resource file each time s/he wants to know, what message is
printed,
because in most cases, the message key will bear no meaning.
(* Compare with the issue we've come across recently: SecurityException:
K00Ec *)
4) Add to this that most of the developers will not know where the
localized messages are kept,
and you'll get the situation when most of the messages are not localized
in any way.
With gettext, localizing for developers is as easy as putting _() around
your string message,
and leaving *everything* else up to the translators. Even the source code
scanning to extract
messages that need to be translated is done automatically with 'xgettext'.
Localized message can contain parameters. E.g. localized message
pattern:
This is message on English with two parameters: parameter number one �C
{0}, ...
with gettext, parameters in localized messages is a non-issue. You can use
printf
or cout with gettext without any restrictions. You even can teach your
program
to use correct plurals.
(* In slavic languages, there is two kind of plurals: 2-4 is dual
plural, 5-9 is multiple plural,
see the concrete example below *)
- All localized messages may be printed through apache log4cxx logger.
gettext's job is to translate strings, and then it's up to developer to
choose
how to print the message, so this requirement is satisfied by gettext.
- Minimize performance impact.
Below is the simple example of using gettext in a toy application to count
apples:
---8--- apples.c
#include locale.h
#include libintl.h
#define _(String) gettext(String)
int main() {
bindtextdomain(apples, .);
textdomain(apples);
setlocale(LC_ALL, NULL);
printf(_(internationalized message\n));
{
int i;
for (i = 0; i 27; i++) {
printf(ngettext(%d apple\n, %d apples\n, i), i);
}
}
return 0;
}
---8---
The translators job then would be to fill in a template with translated
messages, like
--8 ru/LC_MESSAGES/apples.po
msgid internationalized message\n
msgstr русское сообщение\n
msgid %d apple\n
msgid_plural %d apples\n
msgstr[0] %d яблоко\n
msgstr[1] %d яблока\n
msgstr[2] %d яблок\n
---
-
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] proposals for VM internationalization
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on a design decision that the message key
is the *unlocalized message itself*, rather some intermediary constant.
1) Start l10n with the below patch (untested)
2) Start marking localizable strings with _() in the DRLVM source code.
The interface is very simple and does not impose any restrictions.
3) Implement the localization in any way we like, be it icu4c, log4cxx
or gettext. Or may be even leave it configurable at compile time.
There is an essential obstacle to use the *gettext* approach.
It's impossible to run VM on Windows platform if not to take into account
CYGWIN environment.
I'm not clear as well how we will merge the previous .po catalogs (already
translated) with new ones (when new strings to be added).
In any case, a manual work needs for doing this. IMO the gettext is very
convenient to generate the initial template of message catalogs.
However _() should be inserted for all strings (and then deleted?) to
achieve this. It involves too big efforts.
Therefore my preference is to use more universal approach, namely, ICU4C or
LOG4CXX or combination of them.
Any comments?
Thanks,
Vladimir.
--- /dev/null
+++ b/vm/include/l10n.h
@@ -0,0 +1,8 @@
+#ifndef _L10N_H
+#define _L10N_H
+
+#define _(message) (message)
+
+void init_l10n();
+
+#endif // _L10N_H
diff --git a/vm/vmcore/src/init/vm_main.cpp
b/vm/vmcore/src/init/vm_main.cpp
index 9db56e5..96e9a8c 100644
--- a/vm/vmcore/src/init/vm_main.cpp
+++ b/vm/vmcore/src/init/vm_main.cpp
@@ -42,6 +42,7 @@ #include dll_jit_intf.h
#include dll_gc.h
#include em_intf.h
#include port_filepath.h
+#include l10n.h
union Scalar_Arg {
int i;
@@ -283,6 +284,7 @@ static int run_java_shutdown()
void create_vm(Global_Env *p_env, JavaVMInitArgs* vm_arguments)
{
+init_l10n();
#ifdef PLATFORM_POSIX
init_linux_thread_system();
#elif defined(PLATFORM_NT)
diff --git a/vm/vmcore/src/l10n.cpp b/vm/vmcore/src/l10n.cpp
new file mode 100644
index 000..d9d380a
--- /dev/null
+++ b/vm/vmcore/src/l10n.cpp
@@ -0,0 +1,4 @@
+#include l10n.h
+
+void init_l10n() {
+}
-
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] compatibility nuances
On 7/14/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/7/14, Richard Liang [EMAIL PROTECTED]: Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting right order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). I agree with this assertion. The implementation of kernel classes for DRLVM was clean room one. (I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs to specify when same discussions start). We've knew nothing about the algorithms used by RI. All we knew is our implementation should correspond to the specifications and not break them. The case discussed here is such one in my opinion. Could you please give prove why the compatibility needs here? What RI should be used for this purpose if any? Thanks, Vladimir. I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. -- Regards, Alexey Varlamov Best regards, Richard Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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 Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [os] freebsd
On 7/13/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
Some time ago I installed FreeBSD 6.1-RELEASE on my home computer and
tried to build original Harmony VM donation [1] + corresponding
classlib on it. In the end of the efforts I've managed to build it and
print something with '-?' argument, but unfortunately an attempt to
run 'Hello, world' app failed.
The algorithm was straighforward - when a compile error happened, I've
tried to fix it in a straightforward way just to make build pass this
stage, and I'm not surprised that the resulted VM doesn't work :)
Maybe the list of those changes will give an idea what things should
be modified to run Harmony on another platform.
Details:
- I've installed FreeBSD with complete sources (compat included).
- JRE was Diablo-JRE from [2].
- added packages (pkg_add -r) libiconv and libxml2
- linker complained about -ldl missing in many places - I've tried to
removed all -ldl entries but finally gave up and symlinked libdl.so
to libc.so
- replaced everywhere #include malloc.h with #include stdlib.h
- paths to some include files changed and some other includes changed, too
- replaced PTHREAD_MUTEX_RECURSIVE_NP with PTHREAD_MUTEX_RECURSIVE
(_NP stands for non-portable, so I believe it's not a big crime)
- mcontext_t has a slighly different structure, for example
uc_mcontext.gregs[REG_EAX] - uc_mcontext.mc_eax
- sigcontext has a slighly different structure, for example
sigcontext.edi - sigcontext.sc_edi
- flag for shmem SHM_HUGETLB is missing on FreeBSD - I've just removed it
- hysysinfo.c: changed hysysinfo_get_physical_memory to code taken from
[3]
- hysock.c - undefined HAS_RTNETLINK, changed SOL_IPV6 to IPPROTO_IPV6
- hysock.h - undefined GLIBC_R and defined NO_R (maybe better solution
would be ORIGINAL_R and linking with lc_r)
changed
#define OS_IPV6_ADD_MEMBERSHIP IPV6_ADD_MEMBERSHIP
#define OS_IPV6_DROP_MEMBERSHIP IPV6_DROP_MEMBERSHIP
to
#define OS_IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
#define OS_IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
- thrdsup.c - commented out _FPU_GETCW and _FPU_SETCW
- hysiglinux.c - changed sigvec signature
sigvec (int sig, const struct sigvec *invec, struct sigvec *outvec)
to
sigvec (int sig, struct sigvec *invec, struct sigvec *outvec)
- pdsimpl.c - removed option SO_BINDTODEVICE (changed to 0). As far as
I understand, code with that flag returns available network interfaces
- I believe there's a possibility to rewrite in in a FreeBSD way.
Threads are a big problem. On Linux pthread_t is an unsigned int, on
FreeBSD - pthread* .
So things like code from gc_v4.cpp :
for (unsigned int i = 0; i get_num_worker_threads() ; i++) {
// Point the GC thread to the GC object
_gc_threads[i] = new GC_Thread(this, i);
assert(_gc_threads[i]);
}
won't work. I've just added cast to pthread_t but obviously this is
not a proper solution.
After these modifications all modules compiled but linker complained
that some log4cxx functions with wchar_t couldn't be found. Adding
-DLOG4CXX_HAS_WCHAR_T=1 and -D__STDC_ISO_10646__=1 flags to log4xcc
compilation helped . After that ij compiled but attempt to run it
crashed on mutexes. Those calls to mutexes were in sections surrounded
with #if APR_HAS_THREADS and it's no wonder I've recompiled log4cxx
with -DAPR_HAS_THREADS=0 . After that ij finally printed the list of
its options given the -? argument.
I've tried to play with the code further trying to make it run 'Hello,
world' app but failed.
Hope it makes some sence.
Yep, it doesJ. Thanks for your efforts and letting us know about all
problems you faced with.
Sometimes even small fixes for the build system can be a cause of the big
issues to find not easily.
You've made a lot of things are not obvious at first glance and demand an
additional investigation.
In any case your information is very valuable.
Thanks,
Vladimir.
[1] http://issues.apache.org/jira/browse/HARMONY-438
[2] http://www.freebsdfoundation.org/downloads/java.shtml
[3]
http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014733.html
--
Regards,
Anton Luht,
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] questions about build.bat -DEBUILD_CFG=debug -DCXX=msvc
Weldon, why did you pass the EBUILD_CFG but not BUILD_CFG? I believe a reason of your issue is here. Thanks, Vladimir. On 7/13/06, Weldon Washburn [EMAIL PROTECTED] wrote: Hi, I am trying to use the debugger to step through the write barrier support that was recently added to Jitrino.JET. DRLVM is built using build.bat -DEBUILD_CFG=debug -DCXX=msvc. However, it turns out that _DEBUG is not defined and MSVC is definitely optimizing the code. After looking at the build/make files, I noticed that drlvm/trunk/build/make/targets/common_vm.xml contains the lines: select cfg=debug select os=win cxx=icl compilerarg value=/QxN / compilerarg value=/Qip / /select select os=win cxx=msvc compilerarg value=/Ox / /select /select The question is about the compiler switches for cfg=debug,cxx=msvc. It seems /Ox tells the compiler to optimize the code. Interestingly its the same compiler switches that are used in the cfg=release configuration. Maybe its a cut and paste typo?? In any case, I modified the msvc switches to read as below: - select os=win cxx=msvc compilerarg value=/Od / compilerarg value=/MTd / compilerarg value=/D_DEBUG / /select The code is definitely not optimized which is good. But the compiler is still ignoring /D_DEBUG. Any suggestions? -- 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: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Indeed we need to i18d the native code to resolve this issue. I'd suggest to use the log4cxx resource bundle approach for doing this. This one can be suitable for both VMs API natives. I'm going to create new thread to discuss this approach. Thanks, Vladimir. Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). Agree. However we should have the possibility to run the class library tests against any VM. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread will be useless if we put them on the class lib modules. Correct? Thanks, Vladimir. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). Agree. However we should have the possibility to run the class library tests against any VM. Yah, I was pondering the same question, and thinking that we should put spec and intergration-ish tests outside of classlib, maybe in the if-I-keep-wishing-it-will-happen /testing subcomponent, but I don't really care too strongly. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread The tests don't care. I've been playing with running things under DRLVM. I have no doubts it was done. will be useless if we put them on the class lib modules. Correct? I don't actually see why. I thought we cannot run the class library tests under DRLVM. I mean * automatically*. Now I see there is such way (thanks Mark for coaching). Therefore moving the VM-independent test to the luni-kernel module is very useful thingJ. Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Mark Hindess wrote: Salikh Zakirov wrote: Using the fixed classlib snapshot will remove one factor of uncertainty, and will make the DRLVM behaviour more reproducible. -1 Doing this will hide issues that appear when changes to classlib breaks drlvm. At this stage in the project, I'd rather have such issues be as visible as possible. Such breakages should be relatively easy to fix and any drlvm developer should be capable of rolling back classlib svn until things are fixed if they get impatient. I don't see how it significantly affects reproducibility since it is trivial to check/record the versions of classlib and drlvm svn when an error occurs? I agree that recording revision numbers of both classlib and drlvm will be sufficient to reproduce the problem. The hard part is finding the good ones when the latest revisions do not work, in a case when someone wants to work on something different than fixing the latest breakages. I think that the reasonable compromise is to have both capabilities in the build system (build with classlib snapshot or with latest checkout), and leave it up to contributors to decide which way to use. If DRLVM will be built with the class library snapshot we should be sure it doesn't already contain the breakages. It means the responsible person for the class library snapshot should run the VM tests at least. IMO this will complicate the build process due to the possible test failures because it's not clear on this stage where a cause of error is. Therefore I'd prefer to build from scratch using the recent sources. In the case if any problems happen we can take any other revision either class library or DRLVM sources and re-build them if there are any doubts. In any case you need to take the latest version and to check it when you are finally going to commit your changes. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] Harmony's Eclipse plug-in (was: Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties)
On 6/29/06, Tim Ellison [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Geir, I am working on the patch. There is almost no problem, except that DRLVM builds its own modified version of eclipse plugin. The plugin requires eclipse for its build. I see that the same plugin exists in enhanced/tools/eclipse/org.apache.harmony.eclipse.jdt.launching. I think: - all modifications to the plugin should go to this directory. - drlvm should not build eclipse plugin itself, it should be built as part of tools. Correct? I think so. let me ask... why do we *need* the eclipse plugin to build, and even more important, why must it be modified? The purpose of modifications was AFAIK to make it compactible with the name of main executable: 'ij.exe'. It looks that there were also a few bug fixes. It would be helpful if the bug-fixes were raised in JIRA separately so that we can track/fix the plug-in bugs. No, there are no bugs here. Just the original plugin sources have be tuned for the DRLVM specific. Namely, no com.ibm.oti.configuration property is set when the DRLVM is run. In this case the plugin has a different behavior in comparing with the original one. Therefore we need to tune it (please look at the drlvm\trunk\build\patches\hyplugin.patch for details). Otherwise it will not work correctly. Thanks, Vladimir. As for building, the tools package seems not to have own build system. The enhanced/tools/eclipse area does not participate in the classlib build system because they are Eclipse-specific tools, and require an Eclipse installation to compile against etc. If you load the Eclipse tools' source into Eclipse you can build from there. The JDK tools (javac and keytool at the moment) do participate in the classlib build system. The plugin is quite useful for complex testing scenarious: start eclipse, create and run java project from it. So, the question would be, how one could build plugin from tools package? I'm also thinking about snapshot releases of the tools. You should load and build directly in the Eclipse framework, which is the usual way for Eclipse plug-ins. We keep snapshots here http://svn.apache.org/viewvc/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site/plugins/ We discussed having an Eclipse update site but was told that there were plans to have an Apache-wide site. AFAIK that has not come about. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties
On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Geir, I am working on the patch. There is almost no problem, except that DRLVM builds its own modified version of eclipse plugin. The plugin requires eclipse for its build. I see that the same plugin exists in enhanced/tools/eclipse/org.apache.harmony.eclipse.jdt.launching. I think: - all modifications to the plugin should go to this directory. - drlvm should not build eclipse plugin itself, it should be built as part of tools. Correct? I think so. let me ask... why do we *need* the eclipse plugin to build, and even more important, why must it be modified? The purpose of modifications was AFAIK to make it compactible with the name of main executable: 'ij.exe'. It looks that there were also a few bug fixes. I can fix the former in about 3 min... :) Did we run the TCK tests for doing this :)? Thanks, Vladimir. As for building, the tools package seems not to have own build system. The plugin is quite useful for complex testing scenarious: start eclipse, create and run java project from it. So, the question would be, how one could build plugin from tools package? I'm also thinking about snapshot releases of the tools. Yes, at some point, our snapshots will be a full stack - as much of the JRE that we have. Btw, I've already created the patch (H-698) removing eclipse build dependency for drlvm. Eclipse compiler (from classlib's depends) can still be used: export CLASSPATH=..somewhere../classlib/depends/jars/ecj...jar build.sh -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter Ok - going to look at that... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties
On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Geir, I am working on the patch. There is almost no problem, except that DRLVM builds its own modified version of eclipse plugin. The plugin requires eclipse for its build. I see that the same plugin exists in enhanced/tools/eclipse/org.apache.harmony.eclipse.jdt.launching. I think: - all modifications to the plugin should go to this directory. - drlvm should not build eclipse plugin itself, it should be built as part of tools. Correct? I think so. let me ask... why do we *need* the eclipse plugin to build, and even more important, why must it be modified? The purpose of modifications was AFAIK to make it compactible with the name of main executable: 'ij.exe'. It looks that there were also a few bug fixes. I can fix the former in about 3 min... :) Did we run the TCK tests for doing this :)? For changing the name of an exe? I'm sure I'm capable of that without needing a testsuite... Great! We thought slightly else when used 'ij' :). If you will make this thing we need not to forget to correct the patch for the Eclipse plugin: drlvm\trunk\build\patches\hyplugin.patch. I believe it can be removed at all when Tim will look at these changes and take a decision. Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [jira] Resolved: (HARMONY-666) String StringBuffer should be removed from the DRLVM sources.
-- Forwarded message -- From: Vladimir Gorr [EMAIL PROTECTED] Date: Jun 29, 2006 6:33 PM Subject: Re: [jira] Resolved: (HARMONY-666) String StringBuffer should be removed from the DRLVM sources. To: Mark Hindess (JIRA) [EMAIL PROTECTED] On 6/29/06, Mark Hindess (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-666?page=all ] Mark Hindess resolved HARMONY-666: -- Resolution: Fixed Applied in r417969. Yep, it works. Thanks, Mark. However I'd like to underline each of us needs to clean the previous build (I mean, running the build.bat clean; build.bat). Otherwise the older (pre-compiled) classes can be used. It can confuse all who will modify the j.l.String or j.l.StringBuffersources for any development purposes. Thanks, Vladimir. String StringBuffer should be removed from the DRLVM sources. --- Key: HARMONY-666 URL: http://issues.apache.org/jira/browse/HARMONY-666 Project: Harmony Type: Bug Components: VM Reporter: Vladimir Gorr Assignee: Mark Hindess Currently DRLVM has own implementation of the String StringBuffer classes. Please remove the following files from the DRLVM sources: trunk\vm\vmcore\src\kernel_classes\javasrc\java\lang\String.java trunk\vm\vmcore\src\kernel_classes\javasrc\java\lang\StringBuffer.java They have to be taken from the luni.jar instead to eliminate the ambiguity and the possible surprises. -- 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: [jira] Resolved: (HARMONY-666) String StringBuffer should be removed from the DRLVM sources.
On 6/29/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Nice number. Be carefull with this JIRA :) Yes, I warned about this when I saw this number :). Don't worry I've verfied it. No problems have been found out for this devil issue. Thanks, Vladimir. 2006/6/29, Vladimir Gorr [EMAIL PROTECTED]: -- Forwarded message -- From: Vladimir Gorr [EMAIL PROTECTED] Date: Jun 29, 2006 6:33 PM Subject: Re: [jira] Resolved: (HARMONY-666) String StringBuffer should be removed from the DRLVM sources. To: Mark Hindess (JIRA) [EMAIL PROTECTED] On 6/29/06, Mark Hindess (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-666?page=all ] Mark Hindess resolved HARMONY-666: -- Resolution: Fixed Applied in r417969. Yep, it works. Thanks, Mark. However I'd like to underline each of us needs to clean the previous build (I mean, running the build.bat clean; build.bat). Otherwise the older (pre-compiled) classes can be used. It can confuse all who will modify the j.l.String or j.l.StringBuffersources for any development purposes. Thanks, Vladimir. String StringBuffer should be removed from the DRLVM sources. --- Key: HARMONY-666 URL: http://issues.apache.org/jira/browse/HARMONY-666 Project: Harmony Type: Bug Components: VM Reporter: Vladimir Gorr Assignee: Mark Hindess Currently DRLVM has own implementation of the String StringBuffer classes. Please remove the following files from the DRLVM sources: trunk\vm\vmcore\src\kernel_classes\javasrc\java\lang\String.java trunk\vm\vmcore\src\kernel_classes\javasrc\java\lang\StringBuffer.java They have to be taken from the luni.jar instead to eliminate the ambiguity and the possible surprises. -- 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 -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [svn] PROPFIND errors on SVN repository-- please advise
Yes, I also met this problem before. I'd advise you to make the following:
- edit the C:\Documents and Settings\${user}\Application
Data\Subversion\servers file.
You need to set the http-proxy-host http-proxy-port properties with the
corresponding way.
- run the following command to get the SVN server certificate (look at the *
3.12.4 paragraph* from drlvm/trunk/vm/readme file for details):
svn co
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tags
At least I could resolve similar issue performing these steps.
Thanks,
Vladimir.
On 6/29/06, bootjvm [EMAIL PROTECTED] wrote:
All,
Has anyone seen this SVN error before? Please advise:
% svn _something_ ...
svn: PROPFIND request failed on '/repos/asf/incubator/harmony/some/file'
svn: PROPFIND of '/repos/asf/incubator/harmony/some/file' could not
connect to server (https://svn.apache.org)
%
So I tried a simple checkout of the top-level README file:
% svn checkout https://svn.apache.org/repos/asf/incubator/harmony/README
README
svn: PROPFIND of '/repos/asf/incubator/harmony/README' could not connect
to server (https://svn.apache.org)
%
followed by non-secure HTTP route,
% svn checkout http://svn.apache.org/repos/asf/incubator/harmony/README
README
svn: PROPFIND request failed on '/repos/asf/incubator/harmony/README'
svn: PROPFIND of '/repos/asf/incubator/harmony/README': 302 found
(https://svn.apache.org)
%
This happened to me last night, so I decided to wait until this morning
for
the
error to clear, but it persists. Any hints? I have never had any trouble
accessing SVN before...
Thanks,
Dan Lydick
-
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] Can't build native on winXP
On 6/28/06, Matt Benson [EMAIL PROTECTED] wrote: nmake seems to choke looking for a ntwin32.mak file. I don't care too much about the native stuff actually, but I wanted to play with the build system, so I want to make sure I don't break anything. Does anyone have any advice? Matt, you will not have (I very hope) any problems (like nmake) when the build process is run in the Visual Studio enviroment. For this you need to activate the Command Prompt as follows: All Programs/Microsoft Visual Studio .NET 2003/Visual Studio .NET Tools/Visual Studio .NET 2003 Command Prompt Thanks, Vladimir. TIA, Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
