yes - add the bin directory and the default directory to your
LD_LIBRARY_PATH - the launcher will decide that it doesn't need to do
the execv() and will skip it...
geir
On Sep 28, 2006, at 2:31 AM, Armand Navabi wrote:
I followed your suggestions below and made everything build in debug
mode. Now I can put a break in main.c. Thanks.
Also, now I also see debug information when I try to run helloworld.
Perhaps this debugging information is useful.
[EMAIL PROTECTED]
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $
./java helloworld
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=00000004
Signal_Number=0000000b
Error_Value=00000000
Signal_Code=00000001
Handler1=0804B410
Handler2=B7EEFE46
InaccessibleAddress=00000004
EDI=080A87E0
ESI=00000000
EAX=00000000
EBX=B7F17FD4
ECX=00000000
EDX=00000000
EIP=B7F0AD94
ES=C010007B
DS=0000007B
ESP=BFE5194C
EFlags=00210246
CS=00000073
SS=0000007B
EBP=BFE51A68
Module=/lib/ld-linux.so.2
Module_base_address=B7F02000
Aborted
So now that I can put break points, I tried to follow the code in
gdb to
see where it was hanging. In gdb I get to line 1102 in main.c,
which is
the addDirsToPath method, "execv (exeName, argv)". I think that I
remember this being discussed before. I believe gdb is unable to deal
with this call to execv. So, I don't think this is what is making the
VM hang, and now I am unable to follow the execution of "java
helloworld" any further. Is there a way around this?
Here is the gdb results:
(gdb) b main.c:315
Breakpoint 1 at 0x8048e6f: file main.c, line 315.
(gdb) r helloworld
Starting program:
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java
helloworld
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9192)]
[New Thread 32769 (LWP 9195)]
[New Thread 16386 (LWP 9196)]
[Switching to Thread 16384 (LWP 9192)]
Breakpoint 1, gpProtectedMain (args=0xbfc3df90) at main.c:315
315 rc = addDirsToPath(PORTLIB, 2, dirs, argv);
(gdb) s
addDirsToPath (portLibrary=0xbfc3dfb0, count=2,
newPathToAdd=0xbfc3ddb8,
argv=0xbfc3e3a4) at main.c:1015
1015 char *oldPath = NULL;
(gdb) b 1102
Breakpoint 2 at 0x804a7aa: file main.c, line 1102.
(gdb) c
Continuing.
Breakpoint 2, addDirsToPath (portLibrary=0xbfc3dfb0, count=2,
newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1102
1102 execv (exeName, argv);
Oops, some day I made everything build in debug mode locally. And
forgot about it. Currently there is no option for that. TBD,
obviously. I do it with the patch (linux only) like this:
...
No problem. I'm glad it's helpful. I was beginning to worry that
I was
just getting annoying :).
Thanks for the help,
Armand
Thank you for digging into it. That's really valuable. I hope we will
fix the issue soon.
Thanks,
Armand
Egor Pasko wrote:
I solve this by breaking inside launcher after VM lib is loaded,
then
I break somewhere after libjitrino.so is loaded. Then I can break
anywhere :)
looks like this:
break main.c:360
r
dis
break compile_jit_a_method
c
dis
break whatever function you want
You can make it a script via GDB's 'define' and put somewhere in
~/.gdbinit, two scripts are better: first for initial run, the
second
script does the same but reusing old breakpoint numbers:
dis
en 1
r
dis
en 2
c
dis
I should put that into the FAQ, obviously.
And then when I run the program it never stops at the
breakpoint, though I
see the print I have inserted in the code. Secondly, and more
importantly,
if I try to do anything interesting, like run helloworld, gdb
seems to lose
a thread and then hang (says it Cannot find a thread. Invalid
thread
handle). I have to then stop it and go kill it.
this one is probably a separate issue (not connected with "future
shared library load"). Try my above suggestion, please.
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host
libthread_db
library "/lib/libthread_db.so.1".
(gdb) r helloworld
Starting program:
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/
bin/java
helloworld
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 11007)]
[New Thread 32769 (LWP 11010)]
[New Thread 16386 (LWP 11011)]
Cannot find thread 32769: invalid thread handle
(gdb) q
The program is running. Exit anyway? (y or n) y
[1]+ Stopped gdb ./java
Thanks,
Armand
On the 0x1F0 day of Apache Harmony Armand Navabi wrote:
When I try to run ./java helloworld, it just hangs and I have
to kill
the process. I investigated this a little bit, and I found
that it
hangs on the call to FindClass (in main.c line around line
1199).
I am
unable debug with gdb also, so I have resorted to printf's,
and in
jni.cpp, I found the definition of FindClass, and put an
printf to see
what class it is trying to find when it hangs. I see the
following:
Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread
Also, when I run ./java -Xtrace:em, I get the following (and it
hangs):
...
EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V
EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V
EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V
EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V
Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread
Again, it seems to always hang after FindClass is called for
java/lang/Thread.
I have tried setting LD_LIBRARY_PATH as suggested earlier. I
also
have
JAVA_HOME set (and I have tried it with it unset). Everything
seems to
have the same behavior.
[EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/
bin $
echo
$LD_LIBRARY_PATH
/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/
bin/:/
homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/
default
[EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/
bin $
echo
$JAVA_HOME
/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre
I am using Gentoo Linux. Any ideas?
Thanks,
Armand
Gregory Shimansky wrote:
On Friday 22 September 2006 14:31 Egor Pasko wrote:
what makes me really nervous is that I cannot debug in GDB
on Linux
(!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!)
When GDB starts, it becomes broken right after the start:
[New Thread 1080397952 (LWP 13879)]
[New Thread 1083603888 (LWP 13882)]
Cannot find user-level thread for LWP 13879: generic error
Did anybody come across this problem recently? I googled a
little, but
could not find any valuable comments. I remember, there was
no such
problem in older days!! Is that our new ThreadManager that
does
things
like this? or is it something else?
I've seen in another thread. The problem with gdb is caused
because process
reexecs itself with new environment (there is no other way
known
to tell
dynamic linker to use a library path). This is new launcher
feature necessary
to get rid of java shell script and use a real executable.
Ivan Volosyuk investigated the conditions when launcher
performs
execing
itself to set LD_LIBRARY_PATH and it appears (unless fixed
recently) that you
need to set LD_LIBRARY_PATH=<HDK path>/bin/:<HDK path>/bin/
default. Don't
forget a tailing slash in the first path :)
Anyway, to get the correct LD_LIBRARY_PATH which launcher wants
you can get it
from /proc/`pidof java`/environ if you launch a simple java
program and catch
its reexeced environment. If LD_LIBRARY_PATH contents is
equal to
what
launcher wants, reexecing doesn't happen and this allows normal
debugging.
I think we should document this since it is going to stay for a
long time and
is really required for development on Linux.
----------------------------------------------------------------
-----
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-----------------------------------------------------------------
----
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-----------------------------------------------------------------
----
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Egor Pasko, Intel Managed Runtime Division
------------------------------------------------------------------
---
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
------------------------------------------------------------------
---
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--------------------------------------------------------------------
-
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]
