Re: [drlvm] Trouble Building DRLVM
On the 0x1EF day of Apache Harmony Geir Magnusson, Jr. wrote: > Egor Pasko wrote: > >> > >> If invoked with the option "-Xtrace:em", DRLVM prints compilation > >> events as soon as they occur. What makes real fun is that one method > >> starts compilation several times (without success) and receives > >> SEGFAULT after not so many attempts. The bug may be in OPT or in > >> recompilation, not clear now. Will investigate (first, I'll try to > >> compile some methods with JET selectively) > > > > the bug is caused by OPT's incorrect compilation of method > > test_getPackages_V if I move the compilation to JET, the test > > passes. Investigating... > > > > Moving compilation of _one_ method to JET, while _others_ are compiled > > with OPT *is easy*. All you have to do is put debug.emconf file to > > .../jre/bin/default and run with the option -Xem:debug > > This is *really* cool. (Of course, I assume a patch is forthcoming to > fix OPT :) some progress here. I looked through all transformations done by "memopt", they look OK. Now I suspect an enumeration bug in OPT. I created HARMONY-1682 with a more detailed description and a mini-test to reproduce. Stay tuned -- 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] Trouble Building DRLVM
On the 0x1EF day of Apache Harmony Geir Magnusson, Jr. wrote: > Egor Pasko wrote: > >> > >> If invoked with the option "-Xtrace:em", DRLVM prints compilation > >> events as soon as they occur. What makes real fun is that one method > >> starts compilation several times (without success) and receives > >> SEGFAULT after not so many attempts. The bug may be in OPT or in > >> recompilation, not clear now. Will investigate (first, I'll try to > >> compile some methods with JET selectively) > > > > the bug is caused by OPT's incorrect compilation of method > > test_getPackages_V if I move the compilation to JET, the test > > passes. Investigating... > > > > Moving compilation of _one_ method to JET, while _others_ are compiled > > with OPT *is easy*. All you have to do is put debug.emconf file to > > .../jre/bin/default and run with the option -Xem:debug > > This is *really* cool. (Of course, I assume a patch is forthcoming to > fix OPT :) thanks. I am far from understanding what happens, maybe it's not OPT, who is guilty. I guess, the failure occurs from within a stub code in some strange circumstances.. Trying to reduce the test as well as the number of optimizations that OPT performs. > We should capture this in a FAQ... OK, I am taking this job. Time to get along with website :) > geir > > > > > debug.emconf is as follows: > > > > chains=chain1,chain2 > > chain1.jits=JET_DEBUG > > chain2.jits=CD_OPT > > > > chain1.filter=+::test_getPackages_V > > chain1.filter=- > > > > JET_DEBUG.file=jitrino > > CD_OPT.file=jitrino > > > > # Options to be passed to JIT > > > > -Djit.JET_DEBUG.path= > > > > -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen > > > > -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals > > -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method > > -Djit.CD_OPT.path.dce1=cg_dce > > -Djit.CD_OPT.path.dce2=cg_dce > > -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 > > -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc > > -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc > > > > #inliner configuration > > -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- > > -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt > > -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline > > > > -Djit.CD_OPT.arg.codegen.dce1.early=yes > > -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP > > -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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] Trouble Building DRLVM
On the 0x1F0 day of Apache Harmony Geir Magnusson, Jr. wrote: > On Sep 25, 2006, at 11:16 PM, Egor Pasko wrote: > > > On the 0x1F0 day of Apache Harmony Gregory Shimansky wrote: > >> On Friday 22 September 2006 14:31 Egor Pasko wrote: > >>> what makes me really nervous is that I cannot debug in GDB on Linux > >>> (!) > >>> > >>> When GDB starts, it becomes broken right after the start: > >>> [New Thread 1080397952 (LWP 13879)] > >>> [New Thread 1083603888 (LWP 13882)] > >>> Cannot find user-level thread for LWP 13879: generic error > >>> > >>> Did anybody come across this problem recently? I googled a > >>> little, but > >>> could not find any valuable comments. I remember, there was no such > >>> problem in older days!! Is that our new ThreadManager that does > >>> things > >>> like this? or is it something else? > >> > >> I've seen in another thread. The problem with gdb is caused > >> because process > >> reexecs itself with new environment (there is no other way known > >> to tell > >> dynamic linker to use a library path). This is new launcher > >> feature necessary > >> to get rid of java shell script and use a real executable. > >> > >> Ivan Volosyuk investigated the conditions when launcher performs > >> execing > >> itself to set LD_LIBRARY_PATH and it appears (unless fixed > >> recently) that you > >> need to set LD_LIBRARY_PATH=/bin/:/bin/ > >> default. Don't > >> forget a tailing slash in the first path :) > >> > >> Anyway, to get the correct LD_LIBRARY_PATH which launcher wants > >> you can get it > >> from /proc/`pidof java`/environ if you launch a simple java > >> program and catch > >> its reexeced environment. If LD_LIBRARY_PATH contents is equal to > >> what > >> launcher wants, reexecing doesn't happen and this allows normal > >> debugging. > > > > Thanks, Gregory! I saw Ivan's resolution and appreciate his work. > > Tried > > that yesterday, and it worked. Great! > > > >> I think we should document this since it is going to stay for a > >> long time and > >> is really required for development on Linux. > > > > +1 (!!) we need to document this. BTW, I have my own collection of GDB > > tricks that could be useful when debugging. Some of them significantly > > help me from time to time. I would like to contribute them to Harmony. > > > > I would suggest to make a special HOWTO or "Getting Started" for > > DRLVM's Linux debugging. It might seem too specific, but we have a lot > > to tell here, and, IMHO, this is a strong reason to make a separate > > doc. > > > > How to document? My ideas: > > * start from Wiki, when it matures, move to the website > > * make a JIRA with a patch introducing a new, text-only documentation > > file, like README > > * start JIRA with exact patch to the website (probably, it is not the > > easiest way, though, Nadya has a HOWTO for that) > > > > Any suggestions? > > JIRAs or Wiki - either one so we can capture and put on website. It > think that FAQs are useful for this - we can organize by topic... FAQ is a good idea. I'll try it. -- 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] Trouble Building DRLVM
On Sep 25, 2006, at 11:16 PM, Egor Pasko wrote: On the 0x1F0 day of Apache Harmony Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/ default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. Thanks, Gregory! I saw Ivan's resolution and appreciate his work. Tried that yesterday, and it worked. Great! I think we should document this since it is going to stay for a long time and is really required for development on Linux. +1 (!!) we need to document this. BTW, I have my own collection of GDB tricks that could be useful when debugging. Some of them significantly help me from time to time. I would like to contribute them to Harmony. I would suggest to make a special HOWTO or "Getting Started" for DRLVM's Linux debugging. It might seem too specific, but we have a lot to tell here, and, IMHO, this is a strong reason to make a separate doc. How to document? My ideas: * start from Wiki, when it matures, move to the website * make a JIRA with a patch introducing a new, text-only documentation file, like README * start JIRA with exact patch to the website (probably, it is not the easiest way, though, Nadya has a HOWTO for that) Any suggestions? JIRAs or Wiki - either one so we can capture and put on website. It think that FAQs are useful for this - we can organize by topic... -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 25, 2006, at 9:05 PM, Armand Navabi wrote: I have been trying to follow this thread as best as possible. I apologize if this has already been addressed. Does anyone else have the problem of the executable just hanging? I know some people had this problem before, but I wasn't sure what the fix ended up being (if there was one). Here is the problem I am seeing: When I run ./java it runs fine (after I comment out the assertion on line 183 of thread_native_fat_monitor.c). That's fixed now. When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to find when it hangs. I see the following: Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Also, when I run ./java -Xtrace:em, I get the following (and it hangs): ... EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Again, it seems to always hang after FindClass is called for java/lang/Thread. I have tried setting LD_LIBRARY_PATH as suggested earlier. I also have JAVA_HOME set (and I have tried it with it unset). Everything seems to have the same behavior. [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/ homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/ default [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre I am using Gentoo Linux. Any ideas? Can you start a new thread with this - this one is getting stale Thanks, Armand Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/ default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
submit a FAQ patch to JIRA under "website". Just put a question and answer in the body of the JIRA, and we'll do the rest. geir On Sep 25, 2006, at 7:27 PM, Gregory Shimansky wrote: On Friday 22 September 2006 14:31 Egor Pasko wrote: what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1F0 day of Apache Harmony Gregory Shimansky wrote: > On Friday 22 September 2006 14:31 Egor Pasko wrote: > > what makes me really nervous is that I cannot debug in GDB on Linux > > (!) > > > > When GDB starts, it becomes broken right after the start: > > [New Thread 1080397952 (LWP 13879)] > > [New Thread 1083603888 (LWP 13882)] > > Cannot find user-level thread for LWP 13879: generic error > > > > Did anybody come across this problem recently? I googled a little, but > > could not find any valuable comments. I remember, there was no such > > problem in older days!! Is that our new ThreadManager that does things > > like this? or is it something else? > > I've seen in another thread. The problem with gdb is caused because process > reexecs itself with new environment (there is no other way known to tell > dynamic linker to use a library path). This is new launcher feature necessary > to get rid of java shell script and use a real executable. > > Ivan Volosyuk investigated the conditions when launcher performs execing > itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you > need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't > forget a tailing slash in the first path :) > > Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get > it > from /proc/`pidof java`/environ if you launch a simple java program and catch > its reexeced environment. If LD_LIBRARY_PATH contents is equal to what > launcher wants, reexecing doesn't happen and this allows normal debugging. Thanks, Gregory! I saw Ivan's resolution and appreciate his work. Tried that yesterday, and it worked. Great! > I think we should document this since it is going to stay for a long time and > is really required for development on Linux. +1 (!!) we need to document this. BTW, I have my own collection of GDB tricks that could be useful when debugging. Some of them significantly help me from time to time. I would like to contribute them to Harmony. I would suggest to make a special HOWTO or "Getting Started" for DRLVM's Linux debugging. It might seem too specific, but we have a lot to tell here, and, IMHO, this is a strong reason to make a separate doc. How to document? My ideas: * start from Wiki, when it matures, move to the website * make a JIRA with a patch introducing a new, text-only documentation file, like README * start JIRA with exact patch to the website (probably, it is not the easiest way, though, Nadya has a HOWTO for that) Any suggestions? -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
I have been trying to follow this thread as best as possible. I apologize if this has already been addressed. Does anyone else have the problem of the executable just hanging? I know some people had this problem before, but I wasn't sure what the fix ended up being (if there was one). Here is the problem I am seeing: When I run ./java it runs fine (after I comment out the assertion on line 183 of thread_native_fat_monitor.c). When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to find when it hangs. I see the following: Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Also, when I run ./java -Xtrace:em, I get the following (and it hangs): ... EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Again, it seems to always hang after FindClass is called for java/lang/Thread. I have tried setting LD_LIBRARY_PATH as suggested earlier. I also have JAVA_HOME set (and I have tried it with it unset). Everything seems to have the same behavior. [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre I am using Gentoo Linux. Any ideas? Thanks, Armand Gregory Shimansky wrote: > On Friday 22 September 2006 14:31 Egor Pasko wrote: > >> what makes me really nervous is that I cannot debug in GDB on Linux >> (!) >> >> When GDB starts, it becomes broken right after the start: >> [New Thread 1080397952 (LWP 13879)] >> [New Thread 1083603888 (LWP 13882)] >> Cannot find user-level thread for LWP 13879: generic error >> >> Did anybody come across this problem recently? I googled a little, but >> could not find any valuable comments. I remember, there was no such >> problem in older days!! Is that our new ThreadManager that does things >> like this? or is it something else? >> > > I've seen in another thread. The problem with gdb is caused because process > reexecs itself with new environment (there is no other way known to tell > dynamic linker to use a library path). This is new launcher feature necessary > to get rid of java shell script and use a real executable. > > Ivan Volosyuk investigated the conditions when launcher performs execing > itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you > need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't > forget a tailing slash in the first path :) > > Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get > it > from /proc/`pidof java`/environ if you launch a simple java program and catch > its reexeced environment. If LD_LIBRARY_PATH contents is equal to what > launcher wants, reexecing doesn't happen and this allows normal debugging. > > I think we should document this since it is going to stay for a long time and > is really required for development on Linux. > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Friday 22 September 2006 14:31 Egor Pasko wrote: > what makes me really nervous is that I cannot debug in GDB on Linux > (!) > > When GDB starts, it becomes broken right after the start: > [New Thread 1080397952 (LWP 13879)] > [New Thread 1083603888 (LWP 13882)] > Cannot find user-level thread for LWP 13879: generic error > > Did anybody come across this problem recently? I googled a little, but > could not find any valuable comments. I remember, there was no such > problem in older days!! Is that our new ThreadManager that does things > like this? or is it something else? I've seen in another thread. The problem with gdb is caused because process reexecs itself with new environment (there is no other way known to tell dynamic linker to use a library path). This is new launcher feature necessary to get rid of java shell script and use a real executable. Ivan Volosyuk investigated the conditions when launcher performs execing itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you need to set LD_LIBRARY_PATH=/bin/:/bin/default. Don't forget a tailing slash in the first path :) Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get it from /proc/`pidof java`/environ if you launch a simple java program and catch its reexeced environment. If LD_LIBRARY_PATH contents is equal to what launcher wants, reexecing doesn't happen and this allows normal debugging. I think we should document this since it is going to stay for a long time and is really required for development on Linux. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
Egor Pasko wrote: >> >> If invoked with the option "-Xtrace:em", DRLVM prints compilation >> events as soon as they occur. What makes real fun is that one method >> starts compilation several times (without success) and receives >> SEGFAULT after not so many attempts. The bug may be in OPT or in >> recompilation, not clear now. Will investigate (first, I'll try to >> compile some methods with JET selectively) > > the bug is caused by OPT's incorrect compilation of method > test_getPackages_V if I move the compilation to JET, the test > passes. Investigating... > > Moving compilation of _one_ method to JET, while _others_ are compiled > with OPT *is easy*. All you have to do is put debug.emconf file to > .../jre/bin/default and run with the option -Xem:debug This is *really* cool. (Of course, I assume a patch is forthcoming to fix OPT :) We should capture this in a FAQ... geir > > debug.emconf is as follows: > > chains=chain1,chain2 > chain1.jits=JET_DEBUG > chain2.jits=CD_OPT > > chain1.filter=+::test_getPackages_V > chain1.filter=- > > JET_DEBUG.file=jitrino > CD_OPT.file=jitrino > > # Options to be passed to JIT > > -Djit.JET_DEBUG.path= > > -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen > > -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals > -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method > -Djit.CD_OPT.path.dce1=cg_dce > -Djit.CD_OPT.path.dce2=cg_dce > -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 > -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc > -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc > > #inliner configuration > -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- > -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt > -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline > > -Djit.CD_OPT.arg.codegen.dce1.early=yes > -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP > -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1EC day of Apache Harmony Egor Pasko wrote: > On the 0x1EB day of Apache Harmony Egor Pasko wrote: > > On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote: > > > I modified the launcher to include both the vm directory as well as > > > the launcher directory on the PATH/LD_LIBRARY_PATH. > > > > I am not catching .. the launcher directory is known without > > PATH/LD_LIBRARY_PATH. Why should we look at PATH? > > > > > Can those that have been having troubles with shared lib loading give > > > it a try, and report back, and please mention the platform you are > > > running on... > > > > SUSE 9: > > * HelloWorld works without complaining, cool! > > * JAVA_HOME crash is gone, great! > > (but are we not ignoring JAVA_HOME yet?) > > * tests: > > * ThreadTest failed on JET (looks like a known issue:) > > * ~4 tests failed on OPT (ThreadTest too), I'll look at them > > I picked the ClassLoaderTest. It passes on JET and failes on OPT. > Looks like it is time to open a JIRA... If nobody objects, :) I'll > put some words here as an example how to investigate JIT compiler > problems. I hope, it might be useful for people. > > I ran it as a single test like this: > .../jre/bin/java -Xem:opt > -Xbootclasspath/a:$HARMONY/working_classlib/depends/jars/junit_3.8.2/junit.jar:$HARMONY/working_vm/build/lnx_ia32_gcc_debug/semis/kernel.tests/classes > junit.textui.TestRunner java.lang.ClassLoaderTest > > If invoked with the option "-Xtrace:em", DRLVM prints compilation > events as soon as they occur. What makes real fun is that one method > starts compilation several times (without success) and receives > SEGFAULT after not so many attempts. The bug may be in OPT or in > recompilation, not clear now. Will investigate (first, I'll try to > compile some methods with JET selectively) the bug is caused by OPT's incorrect compilation of method test_getPackages_V if I move the compilation to JET, the test passes. Investigating... Moving compilation of _one_ method to JET, while _others_ are compiled with OPT *is easy*. All you have to do is put debug.emconf file to .../jre/bin/default and run with the option -Xem:debug debug.emconf is as follows: chains=chain1,chain2 chain1.jits=JET_DEBUG chain2.jits=CD_OPT chain1.filter=+::test_getPackages_V chain1.filter=- JET_DEBUG.file=jitrino CD_OPT.file=jitrino # Options to be passed to JIT -Djit.JET_DEBUG.path= -Djit.CD_OPT.path=opt_init,translator,optimizer,hir2lir,codegen -Djit.CD_OPT.path.optimizer=ssa,devirt,inline,purge,simplify,uce,dce,lazyexc,memopt,simplify,uce,dce,lower,dessa,statprof,markglobals -Djit.CD_OPT.path.codegen=lock_method,bbp,gcpoints,cafl,dce1,i8l,early_prop,itrace-,native,constraints,dce2,regalloc,spillgen,layout,copy,rce+,stack,break-,iprof-,emitter!,si_insts,gcmap,info,unlock_method -Djit.CD_OPT.path.dce1=cg_dce -Djit.CD_OPT.path.dce2=cg_dce -Djit.CD_OPT.path.regalloc=bp_regalloc1,bp_regalloc2 -Djit.CD_OPT.path.bp_regalloc1=bp_regalloc -Djit.CD_OPT.path.bp_regalloc2=bp_regalloc #inliner configuration -Djit.CD_OPT.CD_OPT_inliner_pipeline.filter=- -Djit.CD_OPT.CD_OPT_inliner_pipeline.path=ssa,devirt -Djit.CD_OPT.arg.optimizer.inline.pipeline=CD_OPT_inliner_pipeline -Djit.CD_OPT.arg.codegen.dce1.early=yes -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc1.regs=ALL_GP -Djit.CD_OPT.arg.codegen.regalloc.bp_regalloc2.regs=ALL_XMM -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On 22 Sep 2006 18:03:02 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1EC day of Apache Harmony Vladimir Gorr wrote: > Why not to reproduce this situation on Windows and not to use the MVS > debugger? > IIRC this problem also exists for Windows. I love Linux. And many other people do. We should be happy debuggers +1 :) -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1EC day of Apache Harmony Vladimir Gorr wrote: > 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) > > > > 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) > > > > > > 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. I love Linux. And many other people do. We should be happy debuggers -- 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] 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) 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) 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] Trouble Building DRLVM
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) 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) what makes me really nervous is that I cannot debug in GDB on Linux (!) When GDB starts, it becomes broken right after the start: [New Thread 1080397952 (LWP 13879)] [New Thread 1083603888 (LWP 13882)] Cannot find user-level thread for LWP 13879: generic error Did anybody come across this problem recently? I googled a little, but could not find any valuable comments. I remember, there was no such problem in older days!! Is that our new ThreadManager that does things like this? or is it something else? -- 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] Trouble Building DRLVM
On Sep 21, 2006, at 2:13 AM, 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? Oh - for windows, it sets PATH, for linux it sets LD_LIBRARY_PATH. So I was just describing things in general. 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 * Eclipse (3.2) runs, but reports NPE on startup. Is that a known bug? java.lang.NullPointerException at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java: 6073) at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java: 3162) at java.lang.Character.isWhitespace(Character.java:3091) at java.lang.Character.isWhitespace(Character.java:3078) [SNIP] I think this is a known problem that someone is looking into. Ok - so it seems that for you, the problem has gone away. We still seem to have it on Gentoo for Armand... geir geir On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. 2) We seem to have a simple problem w/ ld.so on our different platforms. I think the simple solution to avoid having to have multiple copies of stuff is to ensure that the directory of the launcher is included in LD_LIBRARY_PATH, which I thought it was. It turns out it isn't, and I'm therefore trying to figure out why it works on my box. geir On Sep 20, 2006, at 11:59 AM, Ivan Volosyuk wrote: I think the whole idea with current behaviour of JAVA_HOME is bad. Launcher should set JAVA_HOME according to it own invocation path. Launcher should override the variable if it set incorrectly. -- Ivan On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: That appears to be part of the problem Egor, and I've put the initialization into r448241), however, I still get a failure to create the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok if home is pointing to the harmony jre or is unset. The failure looks like an init args corruption? Regards, Tim --- -- 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: 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] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On 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 * Eclipse (3.2) runs, but reports NPE on startup. Is that a known bug? java.lang.NullPointerException at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java:6073) at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java:3162) at java.lang.Character.isWhitespace(Character.java:3091) at java.lang.Character.isWhitespace(Character.java:3078) at java.util.Properties.load(Properties.java:378) at java.util.PropertyResourceBundle.(PropertyResourceBundle.java:44) at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:286) at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:308) at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:308) at java.util.ResourceBundle.getBundle(ResourceBundle.java:132) at org.apache.harmony.luni.util.MsgHelp$1.run(MsgHelp.java:112) at java.security.AccessController.doPrivilegedImpl(Unknown Source) at java.security.AccessController.doPrivileged(Unknown Source) at org.apache.harmony.luni.util.MsgHelp.setLocale(MsgHelp.java:109) at org.apache.harmony.luni.util.Msg.(Msg.java:47) at java.util.zip.ZipFile.openZip(ZipFile.java:116) at java.util.zip.ZipFile.(ZipFile.java:91) at java.util.jar.JarFile.(JarFile.java:165) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.openJarFile(JarURLConnection.java:237) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.findJarFile(JarURLConnection.java:176) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:143) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:159) at java.net.URLClassLoader.findResourceImpl(URLClassLoader.java:714) at java.net.URLClassLoader$5.run(URLClassLoader.java:665) at java.net.URLClassLoader$5.run(URLClassLoader.java:664) at java.security.AccessController.doPrivilegedImpl(Unknown Source) at java.security.AccessController.doPrivileged(Unknown Source) at java.net.URLClassLoader.findResource(URLClassLoader.java:663) at java.lang.ClassLoader$BootstrapLoader.findResource(Unknown Source) at java.lang.ClassLoader.getResource(Unknown Source) at java.lang.ClassLoader.getResourceAsStream(Unknown Source) at java.lang.ClassLoader.getSystemResourceAsStream(Unknown Source) at java.lang.Class.getResourceAsStream(Unknown Source) at com.ibm.icu.impl.ICUData.getStream(ICUData.java:52) at com.ibm.icu.impl.ICUData.getRequiredStream(ICUData.java:97) at com.ibm.icu.impl.UPropertyAliases.(UPropertyAliases.java:122) at com.ibm.icu.lang.UCharacter.(UCharacter.java:5680) at java.lang.Character.isWhitespace(Character.java:3091) at java.lang.Character.isWhitespace(Character.java:3078) at java.util.Properties.load(Properties.java:378) at org.eclipse.core.launcher.Main.load(Main.java:1475) at org.eclipse.core.launcher.Main.loadProperties(Main.java:1446) at org.eclipse.core.launcher.Main.loadConfiguration(Main.java:1429) at org.eclipse.core.launcher.Main.processConfiguration(Main.java:1243) at org.eclipse.core.launcher.Main.basicRun(Main.java:262) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) > geir > > On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: > > > Ok - so to summarize, there are two things here : > > > > 1) We need to find a clean way to get bootclasspath.properties. I > > don't like JAVA_HOME. I'd like to see if we can simply presume a > > structure, with an override property for people that want to do > > weird things. > > > > 2) We seem to have a simple problem w/ ld.so on our different > > platforms. I think the simple solution to avoid having to have > > multiple copies of stuff is to ensure that the directory of the > > launcher is included in LD_LIBRARY_PATH, which I thought it was. > > It turns out it isn't, and I'm therefore trying to
RE: [drlvm] Trouble Building DRLVM
I checked out everything, and did a clean build, and I'm still running into the same issue. Platform: Gentoo Linux Here is what I see: Running just java: [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt.so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference it hangs here. Doing java -showversion [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java -showversion Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java version "1.5.0" pre-alpha : not complete or compatible svn = r448440, (Sep 21 2006), Linux/ia32/gcc 3.4.6, debug build http://incubator.apache.org/harmony it hangs here. Trying to run helloworld: [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/ [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ Thanks, Armand -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 5:49 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Trouble Building DRLVM I modified the launcher to include both the vm directory as well as the launcher directory on the PATH/LD_LIBRARY_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... geir On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: > Ok - so to summarize, there are two things here : > > 1) We need to find a clean way to get bootclasspath.properties. I > don't like JAVA_HOME. I'd like to see if we can simply presume a > structure, with an override property for people that want to do > weird things. > > 2) We seem to have a simple problem w/ ld.so on our different > platforms. I think the simple solution to avoid having to have > multiple copies of stuff is to ensure that the directory of the > launcher is included in LD_LIBRARY_PATH, which I thought it was. > It turns out it isn't, and I'm therefore trying to figure out why > it works on my box. > > geir > > > On Sep 20, 2006, at 11:59 AM, Ivan Volosyuk wrote: > >> I think the whole idea with current behaviour of JAVA_HOME is bad. >> Launcher should set JAVA_HOME according to it own invocation path. >> Launcher should override the variable if it set incorrectly. >> -- >> Ivan >> >> On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >>> That appears to be part of the problem Egor, and I've put the >>> initialization into r448241), however, I still get a failure to >>> create >>> the (IBM) VM when JAVA_HOME is pointing at a different JRE. It >>> works ok >>> if home is pointing to the harmony jre or is unset. The failure >>> looks >>> like an init args corruption? >>> >>> Regards, >>> Tim >> >> - >> 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] Trouble Building DRLVM
On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote: > I'd prefer to understand the problem first, before we start doing > things like this. Sure, I agree. This is a kind of temproary workaround (mostly, for me), that helped to pinpoint the "JAVA_HOME problem" and make a fix. Might be useful for other people now. > As time said in a later not, the bin/ directory is for the VM > stuff, not the general stuff. I agree again. And VM should look for DSOs in "bin" and "bin/" On the JAVA_HOME, I like the idea of ignoring it (especially if RI does so) > geir > > On Sep 20, 2006, at 7:10 AM, Egor Pasko wrote: > > > On the 0x1EA day of Apache Harmony Egor Pasko wrote: > >> On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > >>> On 20 Sep 2006 17:04:57 +0700, Egor Pasko <[EMAIL PROTECTED]> > >>> wrote: > On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > > On 20 Sep 2006 16:06:07 +0700, Egor Pasko > > <[EMAIL PROTECTED]> wrote: > >> On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > >>> > >>> [snip] > >>> > >>> I've also reproduced the problem with DSO. > >>> Just run 'java' from different directory and will get: > >>> java/lang/UnsatisfiedLinkError : Failed loading library > >>> "libhyzlib.so": DSO load failed > >> > >> Using lovely strace ... I found that moving all lib* (except > >> libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/ > >> default > >> solves the DSO load failures for me. > >> > >> HelloWorld and Eclipse work just fine :) > >> > >> (BTW: to reproduce the happy DSO problem, run the launcher not > >> staying > >> at .../jre/bin, but from some other dir) > >> > >> Does anybody experience the same? Time to quickfix the build? :) > > > > Not works for me. Now I receive: > > java/lang/UnsatisfiedLinkError : Failed loading library > > "libhytext.so": DSO load failed > > > > I have also copied all libraries into bin and bin/default. The > > message > > still displayed. > > oh... > what's the strace of loading attempts? > >>> > >>> I forget to copy libicuuc.so.34, strace have showen me that. > >>> After that, no more DSO problem. > >> > >> At least, it works for us. > >> > >> I am stuck with the build at the moment. Cannot make the patch very > >> quickly :( > > > > and.. here is the patch: > > === > > --- working_vm/build/make/build.xml (revision 447819) > > +++ working_vm/build/make/build.xml (working copy) > > @@ -542,8 +542,17 @@ > > > > > > > > + > > > > > > + > > + > > + > > + > > + > > + > > + > > + > > > > > > > > not so elegant, though... but it works > > not sure, if it is "ideologically correct" :) > > ..we rather need to fix runtime paths for the libs.. don't we? > > > > -- > > Egor Pasko, Intel Managed Runtime Division > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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] Trouble Building DRLVM
On Thursday 21 September 2006 03:43 Geir Magnusson Jr. wrote: > On Sep 20, 2006, at 7:28 PM, Gregory Shimansky wrote: > > On Wednesday 20 September 2006 23:47 Geir Magnusson Jr. wrote: > >> Ok - so to summarize, there are two things here : > >> > >> 1) We need to find a clean way to get bootclasspath.properties. I > >> don't like JAVA_HOME. I'd like to see if we can simply presume a > >> structure, with an override property for people that want to do weird > >> things. > > > > I don't think it is so weird. JAVA_HOME setting is ignored by RI > > and I agree > > with it. It is a variable usually used by scripts like ant > > invocation. JRE > > should find its internals itself without any pointer from the user. > > Right. > > > Also before we get a very stable JRE I wouldn't want JAVA_HOME to > > point to > > harmony deploy build. It may result in quite unexpected behavior of > > other > > applications including aforementioned ant. When building Harmony VM > > it cannot > > overwrite JRE directory on windows because ant is being executed by > > Harmony > > JRE already (unless it crashes of course). > > What? You mean actually rewrite JAVA_HOME? No. I just don't want to have it pointing to Harmony JRE deployment directory when I work on it and rebuild it often, then try to run what I have got compiled. If I had to always have JAVA_HOME to point to Harmony JRE I'd have to switch it off and on to run ant every time I need to rebuild. The solution is as you agreed above, JRE shouldn't depend on JAVA_HOME in any way. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 20, 2006, at 7:28 PM, Gregory Shimansky wrote: On Wednesday 20 September 2006 23:47 Geir Magnusson Jr. wrote: Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. I don't think it is so weird. JAVA_HOME setting is ignored by RI and I agree with it. It is a variable usually used by scripts like ant invocation. JRE should find its internals itself without any pointer from the user. Right. Also before we get a very stable JRE I wouldn't want JAVA_HOME to point to harmony deploy build. It may result in quite unexpected behavior of other applications including aforementioned ant. When building Harmony VM it cannot overwrite JRE directory on windows because ant is being executed by Harmony JRE already (unless it crashes of course). What? You mean actually rewrite JAVA_HOME? 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] Trouble Building DRLVM
On Wednesday 20 September 2006 23:47 Geir Magnusson Jr. wrote: > Ok - so to summarize, there are two things here : > > 1) We need to find a clean way to get bootclasspath.properties. I > don't like JAVA_HOME. I'd like to see if we can simply presume a > structure, with an override property for people that want to do weird > things. I don't think it is so weird. JAVA_HOME setting is ignored by RI and I agree with it. It is a variable usually used by scripts like ant invocation. JRE should find its internals itself without any pointer from the user. Also before we get a very stable JRE I wouldn't want JAVA_HOME to point to harmony deploy build. It may result in quite unexpected behavior of other applications including aforementioned ant. When building Harmony VM it cannot overwrite JRE directory on windows because ant is being executed by Harmony JRE already (unless it crashes of course). -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
I modified the launcher to include both the vm directory as well as the launcher directory on the PATH/LD_LIBRARY_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... geir On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. 2) We seem to have a simple problem w/ ld.so on our different platforms. I think the simple solution to avoid having to have multiple copies of stuff is to ensure that the directory of the launcher is included in LD_LIBRARY_PATH, which I thought it was. It turns out it isn't, and I'm therefore trying to figure out why it works on my box. geir On Sep 20, 2006, at 11:59 AM, Ivan Volosyuk wrote: I think the whole idea with current behaviour of JAVA_HOME is bad. Launcher should set JAVA_HOME according to it own invocation path. Launcher should override the variable if it set incorrectly. -- Ivan On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: That appears to be part of the problem Egor, and I've put the initialization into r448241), however, I still get a failure to create the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok if home is pointing to the harmony jre or is unset. The failure looks like an init args corruption? Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM (checkpoint)
On Sep 20, 2006, at 2:55 PM, Geir Magnusson Jr. wrote: I'd prefer to understand the problem first, before we start doing things like this. As time said in a later not, the bin/ directory is for the VM stuff, not the general stuff. er, "Tim" :) Sorry. geir On Sep 20, 2006, at 7:10 AM, Egor Pasko wrote: On the 0x1EA day of Apache Harmony Egor Pasko wrote: On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: On 20 Sep 2006 17:04:57 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: [snip] I've also reproduced the problem with DSO. Just run 'java' from different directory and will get: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed Using lovely strace ... I found that moving all lib* (except libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/ bin/default solves the DSO load failures for me. HelloWorld and Eclipse work just fine :) (BTW: to reproduce the happy DSO problem, run the launcher not staying at .../jre/bin, but from some other dir) Does anybody experience the same? Time to quickfix the build? :) Not works for me. Now I receive: java/lang/UnsatisfiedLinkError : Failed loading library "libhytext.so": DSO load failed I have also copied all libraries into bin and bin/default. The message still displayed. oh... what's the strace of loading attempts? I forget to copy libicuuc.so.34, strace have showen me that. After that, no more DSO problem. At least, it works for us. I am stuck with the build at the moment. Cannot make the patch very quickly :( and.. here is the patch: === --- working_vm/build/make/build.xml (revision 447819) +++ working_vm/build/make/build.xml (working copy) @@ -542,8 +542,17 @@ + + + + + + + + + not so elegant, though... but it works not sure, if it is "ideologically correct" :) ..we rather need to fix runtime paths for the libs.. don't we? -- 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: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
I'd prefer to understand the problem first, before we start doing things like this. As time said in a later not, the bin/ directory is for the VM stuff, not the general stuff. geir On Sep 20, 2006, at 7:10 AM, Egor Pasko wrote: On the 0x1EA day of Apache Harmony Egor Pasko wrote: On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: On 20 Sep 2006 17:04:57 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: [snip] I've also reproduced the problem with DSO. Just run 'java' from different directory and will get: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed Using lovely strace ... I found that moving all lib* (except libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/ default solves the DSO load failures for me. HelloWorld and Eclipse work just fine :) (BTW: to reproduce the happy DSO problem, run the launcher not staying at .../jre/bin, but from some other dir) Does anybody experience the same? Time to quickfix the build? :) Not works for me. Now I receive: java/lang/UnsatisfiedLinkError : Failed loading library "libhytext.so": DSO load failed I have also copied all libraries into bin and bin/default. The message still displayed. oh... what's the strace of loading attempts? I forget to copy libicuuc.so.34, strace have showen me that. After that, no more DSO problem. At least, it works for us. I am stuck with the build at the moment. Cannot make the patch very quickly :( and.. here is the patch: === --- working_vm/build/make/build.xml (revision 447819) +++ working_vm/build/make/build.xml (working copy) @@ -542,8 +542,17 @@ + + + + + + + + + not so elegant, though... but it works not sure, if it is "ideologically correct" :) ..we rather need to fix runtime paths for the libs.. don't we? -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. 2) We seem to have a simple problem w/ ld.so on our different platforms. I think the simple solution to avoid having to have multiple copies of stuff is to ensure that the directory of the launcher is included in LD_LIBRARY_PATH, which I thought it was. It turns out it isn't, and I'm therefore trying to figure out why it works on my box. geir On Sep 20, 2006, at 11:59 AM, Ivan Volosyuk wrote: I think the whole idea with current behaviour of JAVA_HOME is bad. Launcher should set JAVA_HOME according to it own invocation path. Launcher should override the variable if it set incorrectly. -- Ivan On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: That appears to be part of the problem Egor, and I've put the initialization into r448241), however, I still get a failure to create the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok if home is pointing to the harmony jre or is unset. The failure looks like an init args corruption? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
I think the whole idea with current behaviour of JAVA_HOME is bad. Launcher should set JAVA_HOME according to it own invocation path. Launcher should override the variable if it set incorrectly. -- Ivan On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: That appears to be part of the problem Egor, and I've put the initialization into r448241), however, I still get a failure to create the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok if home is pointing to the harmony jre or is unset. The failure looks like an init args corruption? 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: [drlvm] Trouble Building DRLVM
That appears to be part of the problem Egor, and I've put the
initialization into r448241), however, I still get a failure to create
the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok
if home is pointing to the harmony jre or is unset. The failure looks
like an init args corruption?
Regards,
Tim
Egor Pasko wrote:
> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
>> On Sep 19, 2006, at 7:13 AM, Egor Pasko wrote:
>>
>>> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote:
> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
>> For grins, can you set JAVA_HOME to the deploy/jre directory and
>> PATH to
>> include jre/bin?
> lots of grins here :)
> I set them, it runs well (with my patches, but, anyway), this
> problem
What are you patches?
>>> nothing special:
>>> * launcher debug mode (O0, -g)
>>> * libhysig.so included in
>>> modules/luni/src/main/native/launcher/linux/makefile
>>> * hymem_free_memory commented out in
>>> modules/luni/src/main/native/common/shared/strhelp.c
>>> (this one is rather experimantal, the root cause was incorrect
>>>handling of JAVA_HOME)
>> Ah - that's a good hint. I'll see if I can work it out from that.
>>
>>> BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV
>>> in this case is not the best idea. Can we overcome it in some way?
>> LOL. Yes - lets figure out the root cause :)
>
> good news :P
>
> the root cause is: the launcher fails to find
> $JAVA_HOME/lib/boot/bootclasspath.properties and crashes
>
> if $JAVA_HOME/lib exists,
> luniglob.c:216:readClassPathFromPropertiesFile(...) is invoked (which
> contains the bug).
>
> if there is no "bootclasspath.properties" file, the local variable
> "props" stays uninitialized during the "properties_load" call and
> results in a crash here:
>
> luniglob.c:297:
> if (props) {
> properties_free(PORTLIB, props);
> }
>
> the proposed solution is simple:
>
> --- working_classlib/modules/luni/src/main/native/luni/shared/luniglob.c
> (revision 447819)
> +++ working_classlib/modules/luni/src/main/native/luni/shared/luniglob.c
> (working copy)
> @@ -222,7 +222,7 @@
> char *bootstrapClassPath = NULL;
> vmiError rcGetProperty;
> jint returnCode;
> -key_value_pair * props;
> +key_value_pair *props = NULL;
> U_32 number;
>
> /* Extract the port library */
>
>
> P.S.: did anybody try to valgrind DRLVM?
>
--
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] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
> On Sep 19, 2006, at 7:13 AM, Egor Pasko wrote:
>
> > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote:
> >>
> >>> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
> For grins, can you set JAVA_HOME to the deploy/jre directory and
> PATH to
> include jre/bin?
> >>>
> >>> lots of grins here :)
> >>> I set them, it runs well (with my patches, but, anyway), this
> >>> problem
> >>
> >> What are you patches?
> >
> > nothing special:
> > * launcher debug mode (O0, -g)
> > * libhysig.so included in
> > modules/luni/src/main/native/launcher/linux/makefile
> > * hymem_free_memory commented out in
> > modules/luni/src/main/native/common/shared/strhelp.c
> > (this one is rather experimantal, the root cause was incorrect
> >handling of JAVA_HOME)
>
> Ah - that's a good hint. I'll see if I can work it out from that.
>
> >
> > BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV
> > in this case is not the best idea. Can we overcome it in some way?
>
> LOL. Yes - lets figure out the root cause :)
good news :P
the root cause is: the launcher fails to find
$JAVA_HOME/lib/boot/bootclasspath.properties and crashes
if $JAVA_HOME/lib exists,
luniglob.c:216:readClassPathFromPropertiesFile(...) is invoked (which
contains the bug).
if there is no "bootclasspath.properties" file, the local variable
"props" stays uninitialized during the "properties_load" call and
results in a crash here:
luniglob.c:297:
if (props) {
properties_free(PORTLIB, props);
}
the proposed solution is simple:
--- working_classlib/modules/luni/src/main/native/luni/shared/luniglob.c
(revision 447819)
+++ working_classlib/modules/luni/src/main/native/luni/shared/luniglob.c
(working copy)
@@ -222,7 +222,7 @@
char *bootstrapClassPath = NULL;
vmiError rcGetProperty;
jint returnCode;
-key_value_pair * props;
+key_value_pair *props = NULL;
U_32 number;
/* Extract the port library */
P.S.: did anybody try to valgrind DRLVM?
--
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] Trouble Building DRLVM
On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Ivan Volosyuk wrote: > > > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > >> On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > >> > > > >> > [snip] > > >> > > > >> > I've also reproduced the problem with DSO. > > >> > Just run 'java' from different directory and will get: > > >> > java/lang/UnsatisfiedLinkError : Failed loading library > > >> > "libhyzlib.so": DSO load failed > > >> > > >> Using lovely strace ... I found that moving all lib* (except > > >> libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default > > >> solves the DSO load failures for me. > > >> > > >> HelloWorld and Eclipse work just fine :) > > >> > > >> (BTW: to reproduce the happy DSO problem, run the launcher not staying > > >> at .../jre/bin, but from some other dir) > > >> > > >> Does anybody experience the same? Time to quickfix the build? :) > > > > > > Not works for me. Now I receive: > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > "libhytext.so": DSO load failed > > > > > > I have also copied all libraries into bin and bin/default. The message > > > still displayed. > > > > The expected layout is that the classlib libraries reside in jre/bin, > > because they area shared across all VMs, and the VM-specific libraries > > and associated files reside in a subdirectory ore jre/bin (e.g. > > jre/bin/default, or jre/bin/myvm). > > > > Makes sense? > > Tim > > Yes, absolutely. I think it is better for VM's loader to search > libraries in either bin and bin/default. +1 -- 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] Trouble Building DRLVM
On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Ivan Volosyuk wrote: > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: >> On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: >> > >> > [snip] >> > >> > I've also reproduced the problem with DSO. >> > Just run 'java' from different directory and will get: >> > java/lang/UnsatisfiedLinkError : Failed loading library >> > "libhyzlib.so": DSO load failed >> >> Using lovely strace ... I found that moving all lib* (except >> libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default >> solves the DSO load failures for me. >> >> HelloWorld and Eclipse work just fine :) >> >> (BTW: to reproduce the happy DSO problem, run the launcher not staying >> at .../jre/bin, but from some other dir) >> >> Does anybody experience the same? Time to quickfix the build? :) > > Not works for me. Now I receive: > java/lang/UnsatisfiedLinkError : Failed loading library > "libhytext.so": DSO load failed > > I have also copied all libraries into bin and bin/default. The message > still displayed. The expected layout is that the classlib libraries reside in jre/bin, because they area shared across all VMs, and the VM-specific libraries and associated files reside in a subdirectory ore jre/bin (e.g. jre/bin/default, or jre/bin/myvm). Makes sense? Tim Yes, absolutely. I think it is better for VM's loader to search libraries in either bin and bin/default. -- Ivan - 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
Ivan Volosyuk wrote: > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: >> On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: >> > >> > [snip] >> > >> > I've also reproduced the problem with DSO. >> > Just run 'java' from different directory and will get: >> > java/lang/UnsatisfiedLinkError : Failed loading library >> > "libhyzlib.so": DSO load failed >> >> Using lovely strace ... I found that moving all lib* (except >> libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default >> solves the DSO load failures for me. >> >> HelloWorld and Eclipse work just fine :) >> >> (BTW: to reproduce the happy DSO problem, run the launcher not staying >> at .../jre/bin, but from some other dir) >> >> Does anybody experience the same? Time to quickfix the build? :) > > Not works for me. Now I receive: > java/lang/UnsatisfiedLinkError : Failed loading library > "libhytext.so": DSO load failed > > I have also copied all libraries into bin and bin/default. The message > still displayed. The expected layout is that the classlib libraries reside in jre/bin, because they area shared across all VMs, and the VM-specific libraries and associated files reside in a subdirectory ore jre/bin (e.g. jre/bin/default, or jre/bin/myvm). Makes sense? 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: [drlvm] Trouble Building DRLVM
On the 0x1EA day of Apache Harmony Egor Pasko wrote: > On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > > On 20 Sep 2006 17:04:57 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > > > > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > > > > > > > > > > > [snip] > > > > > > > > > > > > I've also reproduced the problem with DSO. > > > > > > Just run 'java' from different directory and will get: > > > > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > > > > "libhyzlib.so": DSO load failed > > > > > > > > > > Using lovely strace ... I found that moving all lib* (except > > > > > libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default > > > > > solves the DSO load failures for me. > > > > > > > > > > HelloWorld and Eclipse work just fine :) > > > > > > > > > > (BTW: to reproduce the happy DSO problem, run the launcher not staying > > > > > at .../jre/bin, but from some other dir) > > > > > > > > > > Does anybody experience the same? Time to quickfix the build? :) > > > > > > > > Not works for me. Now I receive: > > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > > "libhytext.so": DSO load failed > > > > > > > > I have also copied all libraries into bin and bin/default. The message > > > > still displayed. > > > > > > oh... > > > what's the strace of loading attempts? > > > > I forget to copy libicuuc.so.34, strace have showen me that. > > After that, no more DSO problem. > > At least, it works for us. > > I am stuck with the build at the moment. Cannot make the patch very > quickly :( and.. here is the patch: === --- working_vm/build/make/build.xml (revision 447819) +++ working_vm/build/make/build.xml (working copy) @@ -542,8 +542,17 @@ + + + + + + + + + not so elegant, though... but it works not sure, if it is "ideologically correct" :) ..we rather need to fix runtime paths for the libs.. don't we? -- 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] Trouble Building DRLVM
On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > On 20 Sep 2006 17:04:57 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > > > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > > > > > > > > > [snip] > > > > > > > > > > I've also reproduced the problem with DSO. > > > > > Just run 'java' from different directory and will get: > > > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > > > "libhyzlib.so": DSO load failed > > > > > > > > Using lovely strace ... I found that moving all lib* (except > > > > libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default > > > > solves the DSO load failures for me. > > > > > > > > HelloWorld and Eclipse work just fine :) > > > > > > > > (BTW: to reproduce the happy DSO problem, run the launcher not staying > > > > at .../jre/bin, but from some other dir) > > > > > > > > Does anybody experience the same? Time to quickfix the build? :) > > > > > > Not works for me. Now I receive: > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > "libhytext.so": DSO load failed > > > > > > I have also copied all libraries into bin and bin/default. The message > > > still displayed. > > > > oh... > > what's the strace of loading attempts? > > I forget to copy libicuuc.so.34, strace have showen me that. > After that, no more DSO problem. At least, it works for us. I am stuck with the build at the moment. Cannot make the patch very quickly :( -- 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] Trouble Building DRLVM
On 20 Sep 2006 17:04:57 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > > > > > [snip] > > > > > > I've also reproduced the problem with DSO. > > > Just run 'java' from different directory and will get: > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > "libhyzlib.so": DSO load failed > > > > Using lovely strace ... I found that moving all lib* (except > > libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default > > solves the DSO load failures for me. > > > > HelloWorld and Eclipse work just fine :) > > > > (BTW: to reproduce the happy DSO problem, run the launcher not staying > > at .../jre/bin, but from some other dir) > > > > Does anybody experience the same? Time to quickfix the build? :) > > Not works for me. Now I receive: > java/lang/UnsatisfiedLinkError : Failed loading library > "libhytext.so": DSO load failed > > I have also copied all libraries into bin and bin/default. The message > still displayed. oh... what's the strace of loading attempts? I forget to copy libicuuc.so.34, strace have showen me that. After that, no more DSO problem. -- Thanks, Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote: > On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > > > > > [snip] > > > > > > I've also reproduced the problem with DSO. > > > Just run 'java' from different directory and will get: > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > "libhyzlib.so": DSO load failed > > > > Using lovely strace ... I found that moving all lib* (except > > libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default > > solves the DSO load failures for me. > > > > HelloWorld and Eclipse work just fine :) > > > > (BTW: to reproduce the happy DSO problem, run the launcher not staying > > at .../jre/bin, but from some other dir) > > > > Does anybody experience the same? Time to quickfix the build? :) > > Not works for me. Now I receive: > java/lang/UnsatisfiedLinkError : Failed loading library > "libhytext.so": DSO load failed > > I have also copied all libraries into bin and bin/default. The message > still displayed. oh... what's the strace of loading attempts? -- 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] Trouble Building DRLVM
On 20 Sep 2006 16:06:07 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > [snip] > > I've also reproduced the problem with DSO. > Just run 'java' from different directory and will get: > java/lang/UnsatisfiedLinkError : Failed loading library > "libhyzlib.so": DSO load failed Using lovely strace ... I found that moving all lib* (except libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default solves the DSO load failures for me. HelloWorld and Eclipse work just fine :) (BTW: to reproduce the happy DSO problem, run the launcher not staying at .../jre/bin, but from some other dir) Does anybody experience the same? Time to quickfix the build? :) Not works for me. Now I receive: java/lang/UnsatisfiedLinkError : Failed loading library "libhytext.so": DSO load failed I have also copied all libraries into bin and bin/default. The message still displayed. -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > > [snip] > > I've also reproduced the problem with DSO. > Just run 'java' from different directory and will get: > java/lang/UnsatisfiedLinkError : Failed loading library > "libhyzlib.so": DSO load failed Using lovely strace ... I found that moving all lib* (except libhysig.so, hibhyprt.so, libhythr.so) from jre/bin to jre/bin/default solves the DSO load failures for me. HelloWorld and Eclipse work just fine :) (BTW: to reproduce the happy DSO problem, run the launcher not staying at .../jre/bin, but from some other dir) Does anybody experience the same? Time to quickfix the build? :) -- 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] Trouble Building DRLVM
On 9/19/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Keep in mind that the launcher will add the directory of the executable to the LD_LIBRARY_PATH and then exec() itself, so it should load... I can't wait to figure this one out... geir I didn't managed to pass 'build test' either on Linux nor on Windows. Geir, is it works for you? ---vvv On Linux I have: [Smoke tests all passed] [echo] [echo] == [echo] Run kernel tests using jitrino.jet [echo] == [echo] [mkdir] Created dir: /home/ivan/svn/drlvm/trunk/build/ [echo] RUNNING : java.lang.Class1_5Test ... /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. -^^^- Gregory, suggested to add property -Djunit.home=.. to command line but it looks something wrong there. On windows unit tests which are executed at first fails because of: ---- [echo] INFO: TEST test_jthread_get_priority start [echo] ERROR: Assertion '(jthread_set_priority(tts->java_thread, 0))==((0))' failed at C:\work\harmony\drlvm\trunk\ sts\unit\thread\test_java_attrs.c:41 [echo] INFO: TEST test_jthread_get_priority: FAILED [echo] INFO: TEST test_jthread_set_priority start [echo] ERROR: Assertion '(jthread_set_priority(tts->java_thread, 0))==((0))' failed at C:\work\harmony\drlvm\trunk\ sts\unit\thread\test_java_attrs.c:41 ---- -- 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] Trouble Building DRLVM
Ivan Volosyuk wrote: On 9/19/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr. wrote: > > On Sep 19, 2006, at 7:46 AM, Egor Pasko wrote: > >> On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: >> >> this one is repaired with this patch: >> --- modules/luni/src/main/native/launcher/linux/makefile >> (revision 447762) >> +++ modules/luni/src/main/native/launcher/linux/makefile >> (working copy) >> @@ -21,7 +21,7 @@ >> BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ >> $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ >> $(SHAREDSUB)libhlp.o >> -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so >> +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so >> $(DLLPATH)libhysig.so >> EXENAME = $(EXEPATH)java >> >> include $(HY_HDK)/build/make/rules.mk > > So I guess this comes about because we still haven't resolved the dual > libhythrd problem... and the DRLVM thead library uses hysig (I > suppose) and the classlib version doesn't, and the drlvm build uses > the drlvm version both for the launcher and in /default hmmm - Im not sure this is true. So far I've been using the IBM VME, and I still get the error on my SLES9 machine: deploy/jdk/jre/bin/java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory I cannot launch java unless I set LD_LIBRARY_PATH. Can anyone else recreate this with J9? Egor (sounds like your system suffers from the same ailments as mine)? When I run "ldd java" I see the same "libhysig.so => not found" message. It is only when I rebuild with the $(DLLPATH)libhysig.so in the launcher makefile that I no longer need to set LD_LIBRARY_PATH. ld -v gives me 2.15.90.0.1.1, and gcc -v gives 3.3.3, so it looks as if my configuration is older than yours - perhaps this has something to do with it... Regards, Oliver AFAIU, the fix is already commited. Is it works for you? Yup, the fix works for me: linux-gate.so.1 => (0xe000) libhyprt.so => /harmony/svn-checkouts/test/deploy/jdk/jre/bin/libhyprt.so (0x40018000) libhythr.so => /harmony/svn-checkouts/test/deploy/jdk/jre/bin/libhythr.so (0x40035000) libhysig.so => /harmony/svn-checkouts/test/deploy/jdk/jre/bin/libhysig.so (0x4003d000) libm.so.6 => /lib/tls/libm.so.6 (0x4005) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40072000) libc.so.6 => /lib/tls/libc.so.6 (0x40082000) libdl.so.2 => /lib/libdl.so.2 (0x4019c000) /lib/ld-linux.so.2 (0x4000) Regards, Oliver [EMAIL PROTECTED] ~/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin $ ldd java linux-gate.so.1 => (0xe000) libhyprt.so => /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so (0xb7f95000) libhythr.so => /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhythr.so (0xb7ba9000) libhysig.so => /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhysig.so (0xb7ba6000) libm.so.6 => /lib/libm.so.6 (0xb7b5d000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7b4a000) libc.so.6 => /lib/libc.so.6 (0xb7a31000) libdl.so.2 => /lib/libdl.so.2 (0xb7a2d000) librt.so.1 => /lib/librt.so.1 (0xb7a24000) /lib/ld-linux.so.2 (0xb7faa000) -- Ivan > > I don't understand why it isn't affecting me. On my box, ld -version > reports 2.16.91 and gcc -v reports 3.4.6 > > I'll add this as I don't think there is harm for now > > geir > >> >> (note: crlf endings in makefile) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] showing help text (was: Re: [drlvm] Trouble Building DRLVM)
On Sep 19, 2006, at 11:02 AM, Tim Ellison wrote: Geir Magnusson Jr. wrote: On Sep 19, 2006, at 8:37 AM, Ivan Volosyuk wrote: [SNIP] ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/ bin/libhyprt.so: symbol hythrea d_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference After I have commented out: assert(saved_recursion<1); Ok - this is semi-known behavior - the launcher now doesn't do anything, um, intelligent if it is invoked w/o an arguments, and clearly there's something unpleasant going on when it's just the launcher running, probably with our version of the thread library. I'm going to modify the launcher to pass "-help" into the VM when it's been named "java*" so that it behaves like the tools that come with the Sun's, BEA's and IBM's impelmentation. As I mentioned before, you if you pass "-help" or "-showversion" in the creation of the IBM or Sun VM you will get an error, e.g.: C:\temp\sample>test JVMJ9VM007E Command-line option unrecognised: -help Failed to create VM with rc=-6. These command-line flags are handled by the launcher (not the VM). I need to test that for Sun via a launcher, as just doing "java - help" w/ the sun JRE works as expected - it prints help. Since in Harmony there is not a 1:1 correlation of launcher to VM implementation you will have to either print out generic help in the launcher (bad) or go for an extension to the VM interface to get/print help text. How about passing -help to the VM? I don't grok the downside to this. DRLVM works this way now. that way any localization issues are up to the VM provider. Having the launcher print out help based on the executable name would be bad - it has to be some thing else. I believe that you could write a useful generic implementation of version info since VMs put that into system properties. True - we could solve the version problem that way... geir Regards, Tim IOW, I think that users expect : ./java . print help here But we do need to hunt down why it exits so ungracefully - this is a good test case showing problems since it's so simple. 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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 19, 2006, at 10:09 AM, Oliver Deakin wrote: Geir Magnusson Jr. wrote: On Sep 19, 2006, at 7:46 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: this one is repaired with this patch: --- modules/luni/src/main/native/launcher/linux/makefile (revision 447762) +++ modules/luni/src/main/native/launcher/linux/makefile (working copy) @@ -21,7 +21,7 @@ BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ $(SHAREDSUB)libhlp.o -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so $ (DLLPATH)libhysig.so EXENAME = $(EXEPATH)java include $(HY_HDK)/build/make/rules.mk So I guess this comes about because we still haven't resolved the dual libhythrd problem... and the DRLVM thead library uses hysig (I suppose) and the classlib version doesn't, and the drlvm build uses the drlvm version both for the launcher and in /default hmmm - Im not sure this is true. So far I've been using the IBM VME, and I still get the error on my SLES9 machine: deploy/jdk/jre/bin/java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory I cannot launch java unless I set LD_LIBRARY_PATH. Can anyone else recreate this with J9? Egor (sounds like your system suffers from the same ailments as mine)? When I run "ldd java" I see the same "libhysig.so => not found" message. It is only when I rebuild with the $(DLLPATH)libhysig.so in the launcher makefile that I no longer need to set LD_LIBRARY_PATH. ld -v gives me 2.15.90.0.1.1, and gcc -v gives 3.3.3, so it looks as if my configuration is older than yours - perhaps this has something to do with it... Keep in mind that the launcher will add the directory of the executable to the LD_LIBRARY_PATH and then exec() itself, so it should load... I can't wait to figure this one out... geir Regards, Oliver I don't understand why it isn't affecting me. On my box, ld - version reports 2.16.91 and gcc -v reports 3.4.6 I'll add this as I don't think there is harm for now geir (note: crlf endings in makefile) --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: 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vmi] showing help text (was: Re: [drlvm] Trouble Building DRLVM)
Geir Magnusson Jr. wrote: > On Sep 19, 2006, at 8:37 AM, Ivan Volosyuk wrote: > > [SNIP] > >> ./java >> >> Harmony Java launcher >> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software >> Foundation or its licensors, as applicable. >> java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] >> ./java: relocation error: >> /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so: >> >> symbol hythrea >> d_exit, version HYTHR_0.1 not defined in file libhythr.so with link >> time reference >> >> After I have commented out: >> assert(saved_recursion<1); > > Ok - this is semi-known behavior - the launcher now doesn't do anything, > um, intelligent if it is invoked w/o an arguments, and clearly there's > something unpleasant going on when it's just the launcher running, > probably with our version of the thread library. > > I'm going to modify the launcher to pass "-help" into the VM when it's > been named "java*" so that it behaves like the tools that come with the > Sun's, BEA's and IBM's impelmentation. As I mentioned before, you if you pass "-help" or "-showversion" in the creation of the IBM or Sun VM you will get an error, e.g.: C:\temp\sample>test JVMJ9VM007E Command-line option unrecognised: -help Failed to create VM with rc=-6. These command-line flags are handled by the launcher (not the VM). Since in Harmony there is not a 1:1 correlation of launcher to VM implementation you will have to either print out generic help in the launcher (bad) or go for an extension to the VM interface to get/print help text. I believe that you could write a useful generic implementation of version info since VMs put that into system properties. Regards, Tim > IOW, I think that users expect : > > ./java > > . print help here > > > But we do need to hunt down why it exits so ungracefully - this is a > good test case showing problems since it's so simple. > > 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] Trouble Building DRLVM
On 9/19/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr. wrote: > > On Sep 19, 2006, at 7:46 AM, Egor Pasko wrote: > >> On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: >> >> this one is repaired with this patch: >> --- modules/luni/src/main/native/launcher/linux/makefile >> (revision 447762) >> +++ modules/luni/src/main/native/launcher/linux/makefile >> (working copy) >> @@ -21,7 +21,7 @@ >> BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ >> $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ >> $(SHAREDSUB)libhlp.o >> -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so >> +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so >> $(DLLPATH)libhysig.so >> EXENAME = $(EXEPATH)java >> >> include $(HY_HDK)/build/make/rules.mk > > So I guess this comes about because we still haven't resolved the dual > libhythrd problem... and the DRLVM thead library uses hysig (I > suppose) and the classlib version doesn't, and the drlvm build uses > the drlvm version both for the launcher and in /default hmmm - Im not sure this is true. So far I've been using the IBM VME, and I still get the error on my SLES9 machine: deploy/jdk/jre/bin/java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory I cannot launch java unless I set LD_LIBRARY_PATH. Can anyone else recreate this with J9? Egor (sounds like your system suffers from the same ailments as mine)? When I run "ldd java" I see the same "libhysig.so => not found" message. It is only when I rebuild with the $(DLLPATH)libhysig.so in the launcher makefile that I no longer need to set LD_LIBRARY_PATH. ld -v gives me 2.15.90.0.1.1, and gcc -v gives 3.3.3, so it looks as if my configuration is older than yours - perhaps this has something to do with it... Regards, Oliver AFAIU, the fix is already commited. Is it works for you? [EMAIL PROTECTED] ~/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin $ ldd java linux-gate.so.1 => (0xe000) libhyprt.so => /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so (0xb7f95000) libhythr.so => /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhythr.so (0xb7ba9000) libhysig.so => /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhysig.so (0xb7ba6000) libm.so.6 => /lib/libm.so.6 (0xb7b5d000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7b4a000) libc.so.6 => /lib/libc.so.6 (0xb7a31000) libdl.so.2 => /lib/libdl.so.2 (0xb7a2d000) librt.so.1 => /lib/librt.so.1 (0xb7a24000) /lib/ld-linux.so.2 (0xb7faa000) -- Ivan > > I don't understand why it isn't affecting me. On my box, ld -version > reports 2.16.91 and gcc -v reports 3.4.6 > > I'll add this as I don't think there is harm for now > > geir > >> >> (note: crlf endings in makefile) - 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
Geir Magnusson Jr. wrote: On Sep 19, 2006, at 7:46 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: this one is repaired with this patch: --- modules/luni/src/main/native/launcher/linux/makefile (revision 447762) +++ modules/luni/src/main/native/launcher/linux/makefile (working copy) @@ -21,7 +21,7 @@ BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ $(SHAREDSUB)libhlp.o -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so $(DLLPATH)libhysig.so EXENAME = $(EXEPATH)java include $(HY_HDK)/build/make/rules.mk So I guess this comes about because we still haven't resolved the dual libhythrd problem... and the DRLVM thead library uses hysig (I suppose) and the classlib version doesn't, and the drlvm build uses the drlvm version both for the launcher and in /default hmmm - Im not sure this is true. So far I've been using the IBM VME, and I still get the error on my SLES9 machine: deploy/jdk/jre/bin/java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory I cannot launch java unless I set LD_LIBRARY_PATH. Can anyone else recreate this with J9? Egor (sounds like your system suffers from the same ailments as mine)? When I run "ldd java" I see the same "libhysig.so => not found" message. It is only when I rebuild with the $(DLLPATH)libhysig.so in the launcher makefile that I no longer need to set LD_LIBRARY_PATH. ld -v gives me 2.15.90.0.1.1, and gcc -v gives 3.3.3, so it looks as if my configuration is older than yours - perhaps this has something to do with it... Regards, Oliver I don't understand why it isn't affecting me. On my box, ld -version reports 2.16.91 and gcc -v reports 3.4.6 I'll add this as I don't think there is harm for now geir (note: crlf endings in makefile) --Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 19, 2006, at 9:10 AM, Geir Magnusson Jr. wrote: Ok - this is semi-known behavior - the launcher now doesn't do anything, um, intelligent if it is invoked w/o an arguments, and clearly there's something unpleasant going on when it's just the launcher running, probably with our version of the thread library To clarify, that output is right if it can't find "default". I'm going to modify the launcher to pass "-help" into the VM when it's been named "java*" so that it behaves like the tools that come with the Sun's, BEA's and IBM's impelmentation. ... if and only if it can find default and there is a libharmonyvm.so 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] Trouble Building DRLVM
On Sep 19, 2006, at 8:56 AM, Ivan Volosyuk wrote: On 9/19/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/ libhyprt.so: symbol hythrea d_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference After I have commented out: assert(saved_recursion<1); I've also reproduced the problem with DSO. Just run 'java' from different directory and will get: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed I don't see 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: [drlvm] Trouble Building DRLVM
On Sep 19, 2006, at 8:37 AM, Ivan Volosyuk wrote: [SNIP] ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/ libhyprt.so: symbol hythrea d_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference After I have commented out: assert(saved_recursion<1); Ok - this is semi-known behavior - the launcher now doesn't do anything, um, intelligent if it is invoked w/o an arguments, and clearly there's something unpleasant going on when it's just the launcher running, probably with our version of the thread library. I'm going to modify the launcher to pass "-help" into the VM when it's been named "java*" so that it behaves like the tools that come with the Sun's, BEA's and IBM's impelmentation. IOW, I think that users expect : ./java . print help here But we do need to hunt down why it exits so ungracefully - this is a good test case showing problems since it's so simple. 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] Trouble Building DRLVM
On 9/19/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: On 9/19/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > On Sep 19, 2006, at 7:27 AM, Ivan Volosyuk wrote: > > > On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> > > wrote: > >> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: > >> > > >> > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> > >> For grins, can you set JAVA_HOME to the deploy/jre directory and > >> > >> PATH to > >> > >> include jre/bin? > >> > > > >> > > lots of grins here :) > >> > > I set them, it runs well (with my patches, but, anyway), this > >> problem > >> > > >> > What are you patches? > >> > >> nothing special: > >> * launcher debug mode (O0, -g) > >> * libhysig.so included in > >> modules/luni/src/main/native/launcher/linux/makefile > >> * hymem_free_memory commented out in > >> modules/luni/src/main/native/common/shared/strhelp.c > >> (this one is rather experimantal, the root cause was incorrect > >>handling of JAVA_HOME) > >> > >> BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV > >> in this case is not the best idea. Can we overcome it in some way? > >> > >> > > persists: > >> > > java/lang/UnsatisfiedLinkError : Failed loading library > >> > > "libhyzlib.so": DSO load failed > >> > > > >> > > whooa! I feel more comfortable now :) > >> > > >> > Why? why did the DSO load fail? > >> > >> I am afraid, it looks for DSO in ".", which is a wrong assumption :) > >> I'll take a look, but do not promise to be fast)) > >> > >> -- > >> Egor Pasko, Intel Managed Runtime Division > > > > On my computer, with fresh and clean classlib and drlvm. > > Settings: > > JAVA_HOME=./jre > > PATH=./jre/bin > > LD_LIBRARY_PATH=./jre/bin > > ./java > > you don't need to set LD_LIBRARY_PATH > > > > > Harmony Java launcher > > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > > Foundation or its licensors, as applicable. > > java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] > > java: /home/ivan/svn/drlvm/trunk/vm/thread/src/ > > thread_native_fat_monitor.c:183: > > monitor_wait_impl: Assertion `saved_recursion<1' failed. > > Aborted > > Ok, so something is odd here. - it looks like the launcher can't find > the default/libharmonyvm.so file, and the assertion is some bug in > our version of the thread library, since that's the one being used. > > What are you actually building and how? default settings, no changes. classlib/trunk: JAVA: BEA JRockit(R) (build R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-ia32, ) svn update ant fetch-depends ant drlvm/trunk: svn update sh build.sh update sh build.sh clean; sh build.sh running: cd lnx_ia32_gcc_debug/deploy/jre export JAVA_HOME=$PWD cd bin export PATH=$PWD:$PATH ./java Hello Hello ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so: symbol hythrea d_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference After I have commented out: assert(saved_recursion<1); I've also reproduced the problem with DSO. Just run 'java' from different directory and will get: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed > > > > > > unset LD_LIBRARY_PATH > > ./java > > ./java: error while loading shared libraries: libhysig.so: cannot open > > shared object file: No such file or directory > > > > Glibc: 2.3.6 > > gcc: 3.4.5 > > kernel: 2.6.15.6 > > Right, so that's weird, as I have similar versions. > > I just committed the patch to the launcher make file, so please > refresh and try again. Works, no more LD_LIBRARY_PATH needed. -- 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] Trouble Building DRLVM
On 9/19/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 19, 2006, at 7:27 AM, Ivan Volosyuk wrote: > On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> > wrote: >> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: >> > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: >> > >> > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: >> > >> For grins, can you set JAVA_HOME to the deploy/jre directory and >> > >> PATH to >> > >> include jre/bin? >> > > >> > > lots of grins here :) >> > > I set them, it runs well (with my patches, but, anyway), this >> problem >> > >> > What are you patches? >> >> nothing special: >> * launcher debug mode (O0, -g) >> * libhysig.so included in >> modules/luni/src/main/native/launcher/linux/makefile >> * hymem_free_memory commented out in >> modules/luni/src/main/native/common/shared/strhelp.c >> (this one is rather experimantal, the root cause was incorrect >>handling of JAVA_HOME) >> >> BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV >> in this case is not the best idea. Can we overcome it in some way? >> >> > > persists: >> > > java/lang/UnsatisfiedLinkError : Failed loading library >> > > "libhyzlib.so": DSO load failed >> > > >> > > whooa! I feel more comfortable now :) >> > >> > Why? why did the DSO load fail? >> >> I am afraid, it looks for DSO in ".", which is a wrong assumption :) >> I'll take a look, but do not promise to be fast)) >> >> -- >> Egor Pasko, Intel Managed Runtime Division > > On my computer, with fresh and clean classlib and drlvm. > Settings: > JAVA_HOME=./jre > PATH=./jre/bin > LD_LIBRARY_PATH=./jre/bin > ./java you don't need to set LD_LIBRARY_PATH > > Harmony Java launcher > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] > java: /home/ivan/svn/drlvm/trunk/vm/thread/src/ > thread_native_fat_monitor.c:183: > monitor_wait_impl: Assertion `saved_recursion<1' failed. > Aborted Ok, so something is odd here. - it looks like the launcher can't find the default/libharmonyvm.so file, and the assertion is some bug in our version of the thread library, since that's the one being used. What are you actually building and how? default settings, no changes. classlib/trunk: JAVA: BEA JRockit(R) (build R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-ia32, ) svn update ant fetch-depends ant drlvm/trunk: svn update sh build.sh update sh build.sh clean; sh build.sh running: cd lnx_ia32_gcc_debug/deploy/jre export JAVA_HOME=$PWD cd bin export PATH=$PWD:$PATH ./java Hello Hello ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so: symbol hythrea d_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference After I have commented out: assert(saved_recursion<1); > > unset LD_LIBRARY_PATH > ./java > ./java: error while loading shared libraries: libhysig.so: cannot open > shared object file: No such file or directory > > Glibc: 2.3.6 > gcc: 3.4.5 > kernel: 2.6.15.6 Right, so that's weird, as I have similar versions. I just committed the patch to the launcher make file, so please refresh and try again. Works, no more LD_LIBRARY_PATH needed. -- 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] Trouble Building DRLVM
On Sep 19, 2006, at 7:13 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: For grins, can you set JAVA_HOME to the deploy/jre directory and PATH to include jre/bin? lots of grins here :) I set them, it runs well (with my patches, but, anyway), this problem What are you patches? nothing special: * launcher debug mode (O0, -g) * libhysig.so included in modules/luni/src/main/native/launcher/linux/makefile * hymem_free_memory commented out in modules/luni/src/main/native/common/shared/strhelp.c (this one is rather experimantal, the root cause was incorrect handling of JAVA_HOME) Ah - that's a good hint. I'll see if I can work it out from that. BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV in this case is not the best idea. Can we overcome it in some way? LOL. Yes - lets figure out the root cause :) geir persists: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed whooa! I feel more comfortable now :) Why? why did the DSO load fail? I am afraid, it looks for DSO in ".", which is a wrong assumption :) I'll take a look, but do not promise to be fast)) Not really - right now, DRLVM should be using the harmony.properties file in /default. It sets the vm.dir property to the /default directory (yes, this is awful... we need to modify launcher to fix this to another token like LAUNCHER_DIR) and then adds the dir where the launcher is from, as well as LAUNCHER/default to the boostrap library path. geir -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 19, 2006, at 7:27 AM, Ivan Volosyuk wrote: On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: > > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> For grins, can you set JAVA_HOME to the deploy/jre directory and > >> PATH to > >> include jre/bin? > > > > lots of grins here :) > > I set them, it runs well (with my patches, but, anyway), this problem > > What are you patches? nothing special: * launcher debug mode (O0, -g) * libhysig.so included in modules/luni/src/main/native/launcher/linux/makefile * hymem_free_memory commented out in modules/luni/src/main/native/common/shared/strhelp.c (this one is rather experimantal, the root cause was incorrect handling of JAVA_HOME) BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV in this case is not the best idea. Can we overcome it in some way? > > persists: > > java/lang/UnsatisfiedLinkError : Failed loading library > > "libhyzlib.so": DSO load failed > > > > whooa! I feel more comfortable now :) > > Why? why did the DSO load fail? I am afraid, it looks for DSO in ".", which is a wrong assumption :) I'll take a look, but do not promise to be fast)) -- Egor Pasko, Intel Managed Runtime Division On my computer, with fresh and clean classlib and drlvm. Settings: JAVA_HOME=./jre PATH=./jre/bin LD_LIBRARY_PATH=./jre/bin ./java you don't need to set LD_LIBRARY_PATH Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] java: /home/ivan/svn/drlvm/trunk/vm/thread/src/ thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion<1' failed. Aborted Ok, so something is odd here. - it looks like the launcher can't find the default/libharmonyvm.so file, and the assertion is some bug in our version of the thread library, since that's the one being used. What are you actually building and how? unset LD_LIBRARY_PATH ./java ./java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory Glibc: 2.3.6 gcc: 3.4.5 kernel: 2.6.15.6 Right, so that's weird, as I have similar versions. I just committed the patch to the launcher make file, so please refresh and try again. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 19, 2006, at 7:46 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: For grins, can you set JAVA_HOME to the deploy/jre directory and PATH to include jre/bin? lots of grins here :) I set them, it runs well (with my patches, but, anyway), this problem What are you patches? nothing special: * launcher debug mode (O0, -g) * libhysig.so included in modules/luni/src/main/native/launcher/linux/makefile * hymem_free_memory commented out in modules/luni/src/main/native/common/shared/strhelp.c (this one is rather experimantal, the root cause was incorrect handling of JAVA_HOME) BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV in this case is not the best idea. Can we overcome it in some way? persists: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed whooa! I feel more comfortable now :) Why? why did the DSO load fail? I am afraid, it looks for DSO in ".", which is a wrong assumption :) I'll take a look, but do not promise to be fast)) -- Egor Pasko, Intel Managed Runtime Division On my computer, with fresh and clean classlib and drlvm. Settings: JAVA_HOME=./jre PATH=./jre/bin LD_LIBRARY_PATH=./jre/bin ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] java: /home/ivan/svn/drlvm/trunk/vm/thread/src/ thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion<1' failed. Aborted this is what I did not see by myself, did you try commenting the assertion out? unset LD_LIBRARY_PATH ./java ./java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory this one is repaired with this patch: --- modules/luni/src/main/native/launcher/linux/makefile (revision 447762) +++ modules/luni/src/main/native/launcher/linux/makefile (working copy) @@ -21,7 +21,7 @@ BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ $(SHAREDSUB)libhlp.o -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so $ (DLLPATH)libhysig.so EXENAME = $(EXEPATH)java include $(HY_HDK)/build/make/rules.mk So I guess this comes about because we still haven't resolved the dual libhythrd problem... and the DRLVM thead library uses hysig (I suppose) and the classlib version doesn't, and the drlvm build uses the drlvm version both for the launcher and in /default I don't understand why it isn't affecting me. On my box, ld - version reports 2.16.91 and gcc -v reports 3.4.6 I'll add this as I don't think there is harm for now geir (note: crlf endings in makefile) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On 19 Sep 2006 18:46:40 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > > > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: > > > > > > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > > > >> For grins, can you set JAVA_HOME to the deploy/jre directory and > > > >> PATH to > > > >> include jre/bin? > > > > > > > > lots of grins here :) > > > > I set them, it runs well (with my patches, but, anyway), this problem > > > > > > What are you patches? > > > > nothing special: > > * launcher debug mode (O0, -g) > > * libhysig.so included in > > modules/luni/src/main/native/launcher/linux/makefile > > * hymem_free_memory commented out in > > modules/luni/src/main/native/common/shared/strhelp.c > > (this one is rather experimantal, the root cause was incorrect > >handling of JAVA_HOME) > > > > BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV > > in this case is not the best idea. Can we overcome it in some way? > > > > > > persists: > > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > > "libhyzlib.so": DSO load failed > > > > > > > > whooa! I feel more comfortable now :) > > > > > > Why? why did the DSO load fail? > > > > I am afraid, it looks for DSO in ".", which is a wrong assumption :) > > I'll take a look, but do not promise to be fast)) > > > > -- > > Egor Pasko, Intel Managed Runtime Division > > On my computer, with fresh and clean classlib and drlvm. > Settings: > JAVA_HOME=./jre > PATH=./jre/bin > LD_LIBRARY_PATH=./jre/bin > ./java > > Harmony Java launcher > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] > java: /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_fat_monitor.c:183: > monitor_wait_impl: Assertion `saved_recursion<1' failed. > Aborted this is what I did not see by myself, did you try commenting the assertion out? I don't, yet, going to. BTW, when I run some application: "./java Hello" - everything works fine. The problem appears when no arguments specified. > unset LD_LIBRARY_PATH > ./java > ./java: error while loading shared libraries: libhysig.so: cannot open > shared object file: No such file or directory this one is repaired with this patch: --- modules/luni/src/main/native/launcher/linux/makefile(revision 447762) +++ modules/luni/src/main/native/launcher/linux/makefile(working copy) @@ -21,7 +21,7 @@ BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ $(SHAREDSUB)libhlp.o -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so $(DLLPATH)libhysig.so EXENAME = $(EXEPATH)java include $(HY_HDK)/build/make/rules.mk (note: crlf endings in makefile) Going to try this. -- 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] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote: > On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > > > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: > > > > > > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > > > >> For grins, can you set JAVA_HOME to the deploy/jre directory and > > > >> PATH to > > > >> include jre/bin? > > > > > > > > lots of grins here :) > > > > I set them, it runs well (with my patches, but, anyway), this problem > > > > > > What are you patches? > > > > nothing special: > > * launcher debug mode (O0, -g) > > * libhysig.so included in > > modules/luni/src/main/native/launcher/linux/makefile > > * hymem_free_memory commented out in > > modules/luni/src/main/native/common/shared/strhelp.c > > (this one is rather experimantal, the root cause was incorrect > >handling of JAVA_HOME) > > > > BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV > > in this case is not the best idea. Can we overcome it in some way? > > > > > > persists: > > > > java/lang/UnsatisfiedLinkError : Failed loading library > > > > "libhyzlib.so": DSO load failed > > > > > > > > whooa! I feel more comfortable now :) > > > > > > Why? why did the DSO load fail? > > > > I am afraid, it looks for DSO in ".", which is a wrong assumption :) > > I'll take a look, but do not promise to be fast)) > > > > -- > > Egor Pasko, Intel Managed Runtime Division > > On my computer, with fresh and clean classlib and drlvm. > Settings: > JAVA_HOME=./jre > PATH=./jre/bin > LD_LIBRARY_PATH=./jre/bin > ./java > > Harmony Java launcher > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] > java: > /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_fat_monitor.c:183: > monitor_wait_impl: Assertion `saved_recursion<1' failed. > Aborted this is what I did not see by myself, did you try commenting the assertion out? > unset LD_LIBRARY_PATH > ./java > ./java: error while loading shared libraries: libhysig.so: cannot open > shared object file: No such file or directory this one is repaired with this patch: --- modules/luni/src/main/native/launcher/linux/makefile(revision 447762) +++ modules/luni/src/main/native/launcher/linux/makefile(working copy) @@ -21,7 +21,7 @@ BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \ $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \ $(SHAREDSUB)libhlp.o -MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so $(DLLPATH)libhysig.so EXENAME = $(EXEPATH)java include $(HY_HDK)/build/make/rules.mk (note: crlf endings in makefile) -- 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] Trouble Building DRLVM
On 19 Sep 2006 18:13:28 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: > > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> For grins, can you set JAVA_HOME to the deploy/jre directory and > >> PATH to > >> include jre/bin? > > > > lots of grins here :) > > I set them, it runs well (with my patches, but, anyway), this problem > > What are you patches? nothing special: * launcher debug mode (O0, -g) * libhysig.so included in modules/luni/src/main/native/launcher/linux/makefile * hymem_free_memory commented out in modules/luni/src/main/native/common/shared/strhelp.c (this one is rather experimantal, the root cause was incorrect handling of JAVA_HOME) BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV in this case is not the best idea. Can we overcome it in some way? > > persists: > > java/lang/UnsatisfiedLinkError : Failed loading library > > "libhyzlib.so": DSO load failed > > > > whooa! I feel more comfortable now :) > > Why? why did the DSO load fail? I am afraid, it looks for DSO in ".", which is a wrong assumption :) I'll take a look, but do not promise to be fast)) -- Egor Pasko, Intel Managed Runtime Division On my computer, with fresh and clean classlib and drlvm. Settings: JAVA_HOME=./jre PATH=./jre/bin LD_LIBRARY_PATH=./jre/bin ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] java: /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion<1' failed. Aborted unset LD_LIBRARY_PATH ./java ./java: error while loading shared libraries: libhysig.so: cannot open shared object file: No such file or directory Glibc: 2.3.6 gcc: 3.4.5 kernel: 2.6.15.6 -- 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] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: > > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> For grins, can you set JAVA_HOME to the deploy/jre directory and > >> PATH to > >> include jre/bin? > > > > lots of grins here :) > > I set them, it runs well (with my patches, but, anyway), this problem > > What are you patches? nothing special: * launcher debug mode (O0, -g) * libhysig.so included in modules/luni/src/main/native/launcher/linux/makefile * hymem_free_memory commented out in modules/luni/src/main/native/common/shared/strhelp.c (this one is rather experimantal, the root cause was incorrect handling of JAVA_HOME) BTW, I was pointing JAVA_HOME to RI by mistake. Resulting in SIGSEGV in this case is not the best idea. Can we overcome it in some way? > > persists: > > java/lang/UnsatisfiedLinkError : Failed loading library > > "libhyzlib.so": DSO load failed > > > > whooa! I feel more comfortable now :) > > Why? why did the DSO load fail? I am afraid, it looks for DSO in ".", which is a wrong assumption :) I'll take a look, but do not promise to be fast)) -- 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] Trouble Building DRLVM
On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote: On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: For grins, can you set JAVA_HOME to the deploy/jre directory and PATH to include jre/bin? lots of grins here :) I set them, it runs well (with my patches, but, anyway), this problem What are you patches? persists: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed whooa! I feel more comfortable now :) Why? why did the DSO load fail? geir -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On Sep 19, 2006, at 6:30 AM, Egor Pasko wrote:
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
Hm. That should be irrelevant. You should be able to do :
$ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
trunk
$ cd trunk
$ ant switch_svn_vm
$ ant switch_svn_classlib
which should result in a a checkout of classlib SVN head into
'working_classlib', a checkout of DRLVM SVN head into 'working_vm'.
(You could have done just an 'ant' w/ no arguments, that would have
done the above, plus a full build, but that's really targetted at
building snapshots.
Then you have each tree that you can build independently. (I'm doing
all of this from memory, so if some of the ant targets are slightly
wrong, I apologize in advance...) For classlib :
$ cd working_classlib
$ ant fetch-depends
$ ant
and then
$ cd working_vm/build
$ sh build.sh update
$ sh build.sh
some progress:
if I comment out some freemems:
--- working_classlib/modules/luni/src/main/native/common/shared/
strhelp.c (revision 447722)
+++ working_classlib/modules/luni/src/main/native/common/shared/
strhelp.c (working copy)
@@ -93,12 +93,12 @@
if (properties) {
unsigned i = 0;
while (properties[i].key) {
-hymem_free_memory(properties[i].key);
+//hymem_free_memory(properties[i].key);
if (properties[i].value)
-hymem_free_memory(properties[i].value);
+//hymem_free_memory(properties[i].value);
++i;
}
-hymem_free_memory(properties);
+//hymem_free_memory(properties);
}
}
Hm. We'd need to figure out the root cause there...
...it runs, but hangs taking 99%CPU. Hey, I am a dummy! I unset
JAVA_HOME, and it runs well...
What was it set to? When I have JAVA_HOME set to deploy/jre I don't
see any problems.
this is OK for running like ./java, but if I do not run from within
"jre/bin" dir, behaviour is like this:
$ ./jre/bin/java -cp <...> Hello
java/lang/UnsatisfiedLinkError : Failed loading library
"libhyzlib.so": DSO load failed
do you observe the same with the launcher?
Are you using the launcher? If you aren't using the launcher, you
are wasting time, because we are comparing apples and oranges.
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] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > For grins, can you set JAVA_HOME to the deploy/jre directory and PATH to > include jre/bin? lots of grins here :) I set them, it runs well (with my patches, but, anyway), this problem persists: java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO load failed whooa! I feel more comfortable now :) -- 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] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Hm. That should be irrelevant. You should be able to do :
>
> $ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> trunk
> $ cd trunk
> $ ant switch_svn_vm
> $ ant switch_svn_classlib
>
> which should result in a a checkout of classlib SVN head into
> 'working_classlib', a checkout of DRLVM SVN head into 'working_vm'.
> (You could have done just an 'ant' w/ no arguments, that would have
> done the above, plus a full build, but that's really targetted at
> building snapshots.
>
> Then you have each tree that you can build independently. (I'm doing
> all of this from memory, so if some of the ant targets are slightly
> wrong, I apologize in advance...) For classlib :
>
> $ cd working_classlib
> $ ant fetch-depends
> $ ant
>
> and then
>
> $ cd working_vm/build
> $ sh build.sh update
> $ sh build.sh
some progress:
if I comment out some freemems:
--- working_classlib/modules/luni/src/main/native/common/shared/strhelp.c
(revision 447722)
+++ working_classlib/modules/luni/src/main/native/common/shared/strhelp.c
(working copy)
@@ -93,12 +93,12 @@
if (properties) {
unsigned i = 0;
while (properties[i].key) {
-hymem_free_memory(properties[i].key);
+//hymem_free_memory(properties[i].key);
if (properties[i].value)
-hymem_free_memory(properties[i].value);
+//hymem_free_memory(properties[i].value);
++i;
}
-hymem_free_memory(properties);
+//hymem_free_memory(properties);
}
}
...it runs, but hangs taking 99%CPU. Hey, I am a dummy! I unset
JAVA_HOME, and it runs well...
this is OK for running like ./java, but if I do not run from within
"jre/bin" dir, behaviour is like this:
$ ./jre/bin/java -cp <...> Hello
java/lang/UnsatisfiedLinkError : Failed loading library "libhyzlib.so": DSO
load failed
do you observe the same with the launcher?
--
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] Trouble Building DRLVM
For grins, can you set JAVA_HOME to the deploy/jre directory and PATH to include jre/bin? geir Egor Pasko wrote: > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: >> What's different about how you build? > > I just run "ant" from "enhanced/trunk", and when it breaks, I do what > you suggested. There is almost no difference because not many things > are done additionally to switch_svn_vm and switch_svn_classlib. > >> Are you building from SVN source? > > yes, sure, I tried various scenarios of building, but result is the > same: segmentation fault somewhere sopposedly in launcher. At least, > Alexey Varlamov could reproduce it.. > >> Is it release or debug? > > This is debug config. Now I am building the launcher in debug mode and > trying to investivate more... > >> What happens when you run? > > currently it is like this: > > $ ./java -showversion Hello > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > java version "1.5.0" > pre-alpha : not complete or compatible > svn = r447722, (Sep 19 2006), Linux/ia32/gcc 3.3.3, debug build > http://incubator.apache.org/harmony > SIGSEGV in VM code. > Stack trace: > 1: free (??:-1) > 2: ?? (??:-1) > 3: ?? (??:-1) > 4: hymem_free_memory > (/export/users/evpasko/svn/2/harmony/enhanced/trunk/working_classlib/modules/luni/src/main/native/port/linux/hymem.c:115) > 5: ?? (??:-1) > 6: properties_free (../shared/strhelp.c:97) > > Segmentation fault > > >> Egor Pasko wrote: >>> On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: $ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ trunk $ cd trunk $ ant switch_svn_vm $ ant switch_svn_classlib which should result in a a checkout of classlib SVN head into 'working_classlib', a checkout of DRLVM SVN head into 'working_vm'. (You could have done just an 'ant' w/ no arguments, that would have done the above, plus a full build, but that's really targetted at building snapshots. Then you have each tree that you can build independently. (I'm doing all of this from memory, so if some of the ant targets are slightly wrong, I apologize in advance...) For classlib : $ cd working_classlib $ ant fetch-depends $ ant and then $ cd working_vm/build $ sh build.sh update $ sh build.sh >>> Geir, thanks for clarification. I do almost the same thing, but it >>> does NOT solve the problem on SUSE for me yet. The most unpleasant for >>> me here is that GDB does not help: >>> >>> $ gdb java >>> GNU gdb 6.3 >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and you are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for details. >>> This GDB was configured as "i586-suse-linux"...Using host libthread_db >>> library "/lib/tls/libthread_db.so.1". >>> >>> (gdb) handle SIGSEGV stop >>> SignalStop Print Pass to program Description >>> SIGSEGV Yes Yes Yes Segmentation fault >>> (gdb) set args -showversion Hello >>> (gdb) r >>> Starting program: >>> /export/users/evpasko/svn/2/harmony/enhanced/trunk/working_vm/build/deploy/jre/bin/java >>> -showversion Hello >>> [Thread debugging using libthread_db enabled] >>> [New Thread 1080381568 (LWP 4658)] >>> [New Thread 1083587504 (LWP 4661)] >>> Cannot find user-level thread for LWP 4658: generic error >>> (gdb) >>> >>> does GDB work for you? >>> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > What's different about how you build? I just run "ant" from "enhanced/trunk", and when it breaks, I do what you suggested. There is almost no difference because not many things are done additionally to switch_svn_vm and switch_svn_classlib. > Are you building from SVN source? yes, sure, I tried various scenarios of building, but result is the same: segmentation fault somewhere sopposedly in launcher. At least, Alexey Varlamov could reproduce it.. > Is it release or debug? This is debug config. Now I am building the launcher in debug mode and trying to investivate more... > What happens when you run? currently it is like this: $ ./java -showversion Hello Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java version "1.5.0" pre-alpha : not complete or compatible svn = r447722, (Sep 19 2006), Linux/ia32/gcc 3.3.3, debug build http://incubator.apache.org/harmony SIGSEGV in VM code. Stack trace: 1: free (??:-1) 2: ?? (??:-1) 3: ?? (??:-1) 4: hymem_free_memory (/export/users/evpasko/svn/2/harmony/enhanced/trunk/working_classlib/modules/luni/src/main/native/port/linux/hymem.c:115) 5: ?? (??:-1) 6: properties_free (../shared/strhelp.c:97) Segmentation fault > Egor Pasko wrote: > > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> $ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ > >> trunk > >> $ cd trunk > >> $ ant switch_svn_vm > >> $ ant switch_svn_classlib > >> > >> which should result in a a checkout of classlib SVN head into > >> 'working_classlib', a checkout of DRLVM SVN head into 'working_vm'. > >> (You could have done just an 'ant' w/ no arguments, that would have > >> done the above, plus a full build, but that's really targetted at > >> building snapshots. > >> > >> Then you have each tree that you can build independently. (I'm doing > >> all of this from memory, so if some of the ant targets are slightly > >> wrong, I apologize in advance...) For classlib : > >> > >> $ cd working_classlib > >> $ ant fetch-depends > >> $ ant > >> > >> and then > >> > >> $ cd working_vm/build > >> $ sh build.sh update > >> $ sh build.sh > > > > Geir, thanks for clarification. I do almost the same thing, but it > > does NOT solve the problem on SUSE for me yet. The most unpleasant for > > me here is that GDB does not help: > > > > $ gdb java > > GNU gdb 6.3 > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i586-suse-linux"...Using host libthread_db > > library "/lib/tls/libthread_db.so.1". > > > > (gdb) handle SIGSEGV stop > > SignalStop Print Pass to program Description > > SIGSEGV Yes Yes Yes Segmentation fault > > (gdb) set args -showversion Hello > > (gdb) r > > Starting program: > > /export/users/evpasko/svn/2/harmony/enhanced/trunk/working_vm/build/deploy/jre/bin/java > > -showversion Hello > > [Thread debugging using libthread_db enabled] > > [New Thread 1080381568 (LWP 4658)] > > [New Thread 1083587504 (LWP 4661)] > > Cannot find user-level thread for LWP 4658: generic error > > (gdb) > > > > does GDB work for you? > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
What's different about how you build? Are you building from SVN source? Is it release or debug? What happens when you run? geir Egor Pasko wrote: > On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: >> $ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ >> trunk >> $ cd trunk >> $ ant switch_svn_vm >> $ ant switch_svn_classlib >> >> which should result in a a checkout of classlib SVN head into >> 'working_classlib', a checkout of DRLVM SVN head into 'working_vm'. >> (You could have done just an 'ant' w/ no arguments, that would have >> done the above, plus a full build, but that's really targetted at >> building snapshots. >> >> Then you have each tree that you can build independently. (I'm doing >> all of this from memory, so if some of the ant targets are slightly >> wrong, I apologize in advance...) For classlib : >> >> $ cd working_classlib >> $ ant fetch-depends >> $ ant >> >> and then >> >> $ cd working_vm/build >> $ sh build.sh update >> $ sh build.sh > > Geir, thanks for clarification. I do almost the same thing, but it > does NOT solve the problem on SUSE for me yet. The most unpleasant for > me here is that GDB does not help: > > $ gdb java > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i586-suse-linux"...Using host libthread_db > library "/lib/tls/libthread_db.so.1". > > (gdb) handle SIGSEGV stop > SignalStop Print Pass to program Description > SIGSEGV Yes Yes Yes Segmentation fault > (gdb) set args -showversion Hello > (gdb) r > Starting program: > /export/users/evpasko/svn/2/harmony/enhanced/trunk/working_vm/build/deploy/jre/bin/java > -showversion Hello > [Thread debugging using libthread_db enabled] > [New Thread 1080381568 (LWP 4658)] > [New Thread 1083587504 (LWP 4661)] > Cannot find user-level thread for LWP 4658: generic error > (gdb) > > does GDB work for you? > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote: > $ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ > trunk > $ cd trunk > $ ant switch_svn_vm > $ ant switch_svn_classlib > > which should result in a a checkout of classlib SVN head into > 'working_classlib', a checkout of DRLVM SVN head into 'working_vm'. > (You could have done just an 'ant' w/ no arguments, that would have > done the above, plus a full build, but that's really targetted at > building snapshots. > > Then you have each tree that you can build independently. (I'm doing > all of this from memory, so if some of the ant targets are slightly > wrong, I apologize in advance...) For classlib : > > $ cd working_classlib > $ ant fetch-depends > $ ant > > and then > > $ cd working_vm/build > $ sh build.sh update > $ sh build.sh Geir, thanks for clarification. I do almost the same thing, but it does NOT solve the problem on SUSE for me yet. The most unpleasant for me here is that GDB does not help: $ gdb java GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) handle SIGSEGV stop SignalStop Print Pass to program Description SIGSEGV Yes Yes Yes Segmentation fault (gdb) set args -showversion Hello (gdb) r Starting program: /export/users/evpasko/svn/2/harmony/enhanced/trunk/working_vm/build/deploy/jre/bin/java -showversion Hello [Thread debugging using libthread_db enabled] [New Thread 1080381568 (LWP 4658)] [New Thread 1083587504 (LWP 4661)] Cannot find user-level thread for LWP 4658: generic error (gdb) does GDB work for you? -- 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] Trouble Building DRLVM
On Sep 18, 2006, at 9:58 PM, [EMAIL PROTECTED] wrote: Geir, Thanks. I got it the DRLVM to build now, but I'm coming across problems running it. First, let me mention a couple things about the README that I found, while trying to build the VM. Yah - if you followed the thread you started, it's clearly out of date :) 1. I had to remove the revision tag (-r revision_number) for the downloading of software and tools. There were two places in the file lnx.properties where I removed svn's -r tag. Perhaps this is why I am currently having trouble running it. But without removing the -r tag, I kept getting a 'Secure connection truncated' error message, causing the build to fail. Hm. That should be irrelevant. You should be able to do : $ svn co https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ trunk $ cd trunk $ ant switch_svn_vm $ ant switch_svn_classlib which should result in a a checkout of classlib SVN head into 'working_classlib', a checkout of DRLVM SVN head into 'working_vm'. (You could have done just an 'ant' w/ no arguments, that would have done the above, plus a full build, but that's really targetted at building snapshots. Then you have each tree that you can build independently. (I'm doing all of this from memory, so if some of the ant targets are slightly wrong, I apologize in advance...) For classlib : $ cd working_classlib $ ant fetch-depends $ ant and then $ cd working_vm/build $ sh build.sh update $ sh build.sh 2. Geir's comment fixed the other problem I had (i.e. change drlvm.properties to point to classlib). I should have seen this one on my own but, just for the record, I don't think there is anything in the README about this. Nope. The README is horribly out of date. I'll make it a point to update today. After those two things, the build is just fine. After that, the README starts talking about ij.sh, which I don't even see in the deploy/jre/bin directory. What I do see is a file called java. I have set my LD_LIBRARY_PATH to /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin. So, here is what happens when I tried to run it: /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin>./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] java: /Harmony/enhanced/drlvm/trunk/vm/thread/src/ thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion<1' failed. Aborted Weird. What platform, btw? What I do these days is build classlib, and then build drlvm. You should then be able to do this : $ cd workign_vm/build/deploy/jre $ export JAVA_HOME=`pwd` $ cd bin $ export PATH=`pwd`:$PATH and it should work. Also, if I try to run a java program it just hangs. After this, I searched the mailing list archives for this problem, and found this: http://mail-archives.apache.org/mod_mbox/incubator-harmony-commits/ 200608.mbox/[EMAIL PROTECTED] So, since my problem looked similar I changed the assertion, but now I get this: /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin>./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt.so: symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference This looks like I may have the wrong version of one of these lib files. Any ideas on what I am doing wrong? Amazing. So - what platform are you working on? Clearly some kind of linux. Second, what happens if you set JAVA_HOME as suggested above? geir Thanks in advance for your help, Armand Quoting "Geir Magnusson Jr." <[EMAIL PROTECTED]>: Morozova, Nadezhda wrote: Geir, Ok - it's clear I need to doc this. This is a trigger phrase for me. We have README and Getting Started for DRLVM that are terribly out-of-date. Now, if we update them, and keep them up-to-date, Armand would not need to write to the mailing list but would just follow the guide to successfully build DRLVM :) Indeed! Can you help me update those docs? README is probably of the greatest urgency. I can use your explanation below, but there are other things in the file that need your attention ;) Sure. :) geir Best regards, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, September 18, 2006 8:20 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Trouble Building DRLVM Armand Navabi wrote: I am new to using Harmony. I am currently having trouble getting the DRLVM to build. I have a successful build of th
Re: [drlvm] Trouble Building DRLVM
Geir, Thanks. I got it the DRLVM to build now, but I'm coming across problems running it. First, let me mention a couple things about the README that I found, while trying to build the VM. 1. I had to remove the revision tag (-r revision_number) for the downloading of software and tools. There were two places in the file lnx.properties where I removed svn's -r tag. Perhaps this is why I am currently having trouble running it. But without removing the -r tag, I kept getting a 'Secure connection truncated' error message, causing the build to fail. 2. Geir's comment fixed the other problem I had (i.e. change drlvm.properties to point to classlib). I should have seen this one on my own but, just for the record, I don't think there is anything in the README about this. After those two things, the build is just fine. After that, the README starts talking about ij.sh, which I don't even see in the deploy/jre/bin directory. What I do see is a file called java. I have set my LD_LIBRARY_PATH to /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin. So, here is what happens when I tried to run it: /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin>./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] java: /Harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_fat_monitor.c:183: monitor_wait_impl: Assertion `saved_recursion<1' failed. Aborted Also, if I try to run a java program it just hangs. After this, I searched the mailing list archives for this problem, and found this: http://mail-archives.apache.org/mod_mbox/incubator-harmony-commits/200608.mbox/[EMAIL PROTECTED] So, since my problem looked similar I changed the assertion, but now I get this: /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin>./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt.so: symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference This looks like I may have the wrong version of one of these lib files. Any ideas on what I am doing wrong? Thanks in advance for your help, Armand Quoting "Geir Magnusson Jr." <[EMAIL PROTECTED]>: > > > Morozova, Nadezhda wrote: > > Geir, > > > >> Ok - it's clear I need to doc this. > > > > This is a trigger phrase for me. We have README and Getting Started for > > DRLVM that are terribly out-of-date. Now, if we update them, and keep > > them up-to-date, Armand would not need to write to the mailing list but > > would just follow the guide to successfully build DRLVM :) > > Indeed! > > > > > Can you help me update those docs? README is probably of the greatest > > urgency. I can use your explanation below, but there are other things in > > the file that need your attention ;) > > Sure. :) > > geir > > > > > Best regards, > > Nadya Morozova > > > > -----Original Message- > > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 18, 2006 8:20 PM > > To: harmony-dev@incubator.apache.org > > Subject: Re: [drlvm] Trouble Building DRLVM > > > > > > > > Armand Navabi wrote: > >> I am new to using Harmony. I am currently having trouble getting the > >> DRLVM to build. I have a successful build of the class library. I > > have > >> the following error when I try to ./build.sh update: > >> > >> [mkdir] Created dir: > >> /u/u12/anavabi/Harmony_VM/build/pre-copied/archives/common/XALAN > >> [echo] downloading XALAN from > > no_settings_in_config_or_environment > > > > Ok - it's clear I need to doc this. > > > > DRLVM depends on knowing where the claslibrary is because it uses > > headers and libraries from it when building, and copies stuff when > > assembling the jre. > > > > So, by default, the DRLVM assumes that it and the classlibrary are > > located as follows, relative to each other : > > > > enhanced/classlib/trunk > > > > enhanced/drlvm/trunk > > > > So if that relationship isn't the way it is on your machine, then you > > will have problems like you see, as DRLVM "looks over" into classlib to > > see if XALAN is there as a check. > > > > The solution is to go : > > > > $ cd drlvm/trunk/build > > $ cp drlvm.properties.example d
Re: [drlvm] Trouble Building DRLVM
Morozova, Nadezhda wrote:
Geir,
Ok - it's clear I need to doc this.
This is a trigger phrase for me. We have README and Getting Started for
DRLVM that are terribly out-of-date. Now, if we update them, and keep
them up-to-date, Armand would not need to write to the mailing list but
would just follow the guide to successfully build DRLVM :)
Indeed!
Can you help me update those docs? README is probably of the greatest
urgency. I can use your explanation below, but there are other things in
the file that need your attention ;)
Sure. :)
geir
Best regards,
Nadya Morozova
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Monday, September 18, 2006 8:20 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Trouble Building DRLVM
Armand Navabi wrote:
I am new to using Harmony. I am currently having trouble getting the
DRLVM to build. I have a successful build of the class library. I
have
the following error when I try to ./build.sh update:
[mkdir] Created dir:
/u/u12/anavabi/Harmony_VM/build/pre-copied/archives/common/XALAN
[echo] downloading XALAN from
no_settings_in_config_or_environment
Ok - it's clear I need to doc this.
DRLVM depends on knowing where the claslibrary is because it uses
headers and libraries from it when building, and copies stuff when
assembling the jre.
So, by default, the DRLVM assumes that it and the classlibrary are
located as follows, relative to each other :
enhanced/classlib/trunk
enhanced/drlvm/trunk
So if that relationship isn't the way it is on your machine, then you
will have problems like you see, as DRLVM "looks over" into classlib to
see if XALAN is there as a check.
The solution is to go :
$ cd drlvm/trunk/build
$ cp drlvm.properties.example drlvm.properties
and them modify drlvm.properties so that it finds the right classlib
root. I believe it's relative to trunk/build.
When you then type sh build.sh, it will print out the classslib
location. if it's not right, repeat :)
geir
BUILD FAILED
/u/u12/anavabi/Harmony_VM/build/make/build.xml:238: The following
error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:289: The following
error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:291: The following
error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:462: Warning: Could not
find file
/u/u12/anavabi/Harmony_VM/build/make/no_settings_in_config_or_environmen
t
to copy.
Not sure why the ${remote.resource.archive} variable in setup.xml is
no_settings_in_config_or_environment. Any help is appreciated.
Thanks,
Armand
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : 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] Trouble Building DRLVM
Geir,
> Ok - it's clear I need to doc this.
This is a trigger phrase for me. We have README and Getting Started for
DRLVM that are terribly out-of-date. Now, if we update them, and keep
them up-to-date, Armand would not need to write to the mailing list but
would just follow the guide to successfully build DRLVM :)
Can you help me update those docs? README is probably of the greatest
urgency. I can use your explanation below, but there are other things in
the file that need your attention ;)
Best regards,
Nadya Morozova
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Monday, September 18, 2006 8:20 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Trouble Building DRLVM
Armand Navabi wrote:
> I am new to using Harmony. I am currently having trouble getting the
> DRLVM to build. I have a successful build of the class library. I
have
> the following error when I try to ./build.sh update:
>
> [mkdir] Created dir:
> /u/u12/anavabi/Harmony_VM/build/pre-copied/archives/common/XALAN
> [echo] downloading XALAN from
no_settings_in_config_or_environment
Ok - it's clear I need to doc this.
DRLVM depends on knowing where the claslibrary is because it uses
headers and libraries from it when building, and copies stuff when
assembling the jre.
So, by default, the DRLVM assumes that it and the classlibrary are
located as follows, relative to each other :
enhanced/classlib/trunk
enhanced/drlvm/trunk
So if that relationship isn't the way it is on your machine, then you
will have problems like you see, as DRLVM "looks over" into classlib to
see if XALAN is there as a check.
The solution is to go :
$ cd drlvm/trunk/build
$ cp drlvm.properties.example drlvm.properties
and them modify drlvm.properties so that it finds the right classlib
root. I believe it's relative to trunk/build.
When you then type sh build.sh, it will print out the classslib
location. if it's not right, repeat :)
geir
>
> BUILD FAILED
> /u/u12/anavabi/Harmony_VM/build/make/build.xml:238: The following
error
> occurred while executing this line:
> /u/u12/anavabi/Harmony_VM/build/make/setup.xml:289: The following
error
> occurred while executing this line:
> /u/u12/anavabi/Harmony_VM/build/make/setup.xml:291: The following
error
> occurred while executing this line:
> /u/u12/anavabi/Harmony_VM/build/make/setup.xml:462: Warning: Could not
> find file
>
/u/u12/anavabi/Harmony_VM/build/make/no_settings_in_config_or_environmen
t
> to copy.
>
> Not sure why the ${remote.resource.archive} variable in setup.xml is
> no_settings_in_config_or_environment. Any help is appreciated.
>
> Thanks,
> Armand
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Trouble Building DRLVM
Armand Navabi wrote:
I am new to using Harmony. I am currently having trouble getting the
DRLVM to build. I have a successful build of the class library. I have
the following error when I try to ./build.sh update:
[mkdir] Created dir:
/u/u12/anavabi/Harmony_VM/build/pre-copied/archives/common/XALAN
[echo] downloading XALAN from no_settings_in_config_or_environment
Ok - it's clear I need to doc this.
DRLVM depends on knowing where the claslibrary is because it uses
headers and libraries from it when building, and copies stuff when
assembling the jre.
So, by default, the DRLVM assumes that it and the classlibrary are
located as follows, relative to each other :
enhanced/classlib/trunk
enhanced/drlvm/trunk
So if that relationship isn't the way it is on your machine, then you
will have problems like you see, as DRLVM "looks over" into classlib to
see if XALAN is there as a check.
The solution is to go :
$ cd drlvm/trunk/build
$ cp drlvm.properties.example drlvm.properties
and them modify drlvm.properties so that it finds the right classlib
root. I believe it's relative to trunk/build.
When you then type sh build.sh, it will print out the classslib
location. if it's not right, repeat :)
geir
BUILD FAILED
/u/u12/anavabi/Harmony_VM/build/make/build.xml:238: The following error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:289: The following error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:291: The following error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:462: Warning: Could not
find file
/u/u12/anavabi/Harmony_VM/build/make/no_settings_in_config_or_environment
to copy.
Not sure why the ${remote.resource.archive} variable in setup.xml is
no_settings_in_config_or_environment. Any help is appreciated.
Thanks,
Armand
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] Trouble Building DRLVM
I am new to using Harmony. I am currently having trouble getting the
DRLVM to build. I have a successful build of the class library. I have
the following error when I try to ./build.sh update:
[mkdir] Created dir:
/u/u12/anavabi/Harmony_VM/build/pre-copied/archives/common/XALAN
[echo] downloading XALAN from no_settings_in_config_or_environment
BUILD FAILED
/u/u12/anavabi/Harmony_VM/build/make/build.xml:238: The following error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:289: The following error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:291: The following error
occurred while executing this line:
/u/u12/anavabi/Harmony_VM/build/make/setup.xml:462: Warning: Could not
find file
/u/u12/anavabi/Harmony_VM/build/make/no_settings_in_config_or_environment
to copy.
Not sure why the ${remote.resource.archive} variable in setup.xml is
no_settings_in_config_or_environment. Any help is appreciated.
Thanks,
Armand
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
