harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armand Navabi <anav...@purdue.edu>
Subject Re: [drlvm] [launcher] Executable hangs
Date Thu, 28 Sep 2006 06:31:12 GMT
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.

anavabi@gator
/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.
>>>>>> anavabi@gator ~/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
>>>>>> anavabi@gator ~/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-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>>
>>>>>>         
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>> -- 
>>>> Egor Pasko, Intel Managed Runtime Division
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>>       
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>     
>
>   


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message