harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] [launcher] Executable hangs
Date Fri, 29 Sep 2006 04:45:58 GMT
On the 0x1F3 day of Apache Harmony Armand Navabi wrote:
> Making progress...
> 
> Ok, the problem with execv() has been solved.  It wasn't finding the
> path because of a stupid mistake on my part.  Here was the problem:
> 
> 1047        if (newPathToAdd[i] != NULL && strstr(oldPath,
> newPathToAdd[i]) != 0) {
> (gdb) p newPathToAdd[i]
> $2 = 0x8067ae8
> "/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default"
> (gdb) p oldPath
> $3 = 0xbfe4c554
> "/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default"
> 
> I had to change /homes/anavabi to /u/u12/anavabi in LD_LIBRARY_PATH and
> then the paths are found, so it never gets to the execv line.  FYI, the
> default directory is the one that should not contain a trailing slash. 
> Thanks for the help on this one. 
> 
> Now gdb is working like a champ, but "java helloworld" is still having
> problems.  Here is a stack trace of what happens when I try to run
> helloworld in gdb:
> 
> (gdb) run 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 12424)]
> [New Thread 32769 (LWP 12427)]
> [New Thread 16386 (LWP 12428)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 12424)]
> 0xb7f72d94 in _dl_relocate_object () from /lib/ld-linux.so.2
> 
> (gdb) bt
> #0  0xb7f72d94 in _dl_relocate_object () from /lib/ld-linux.so.2
> #1  0xb7a99fa3 in getutmpx () from /lib/libc.so.6
> #2  0xb7f75862 in _dl_catch_error () from /lib/ld-linux.so.2
> #3  0xb7a9a745 in _dl_open () from /lib/libc.so.6
> #4  0xb79aed00 in ?? () from /lib/libdl.so.2
> #5  0xfffffffe in ?? ()
> #6  0xb7f80000 in ?? () from /lib/ld-linux.so.2
> #7  0xbf9cab68 in ?? ()
> #8  0xb7f7ffd4 in ?? () from /lib/ld-linux.so.2
> #9  0xb7f7fca0 in ?? () from /lib/ld-linux.so.2
> #10 0x0000000c in ?? ()
> #11 0xbf9cac38 in ?? ()
> #12 0xb7f75862 in _dl_catch_error () from /lib/ld-linux.so.2
> #13 0xb7f75862 in _dl_catch_error () from /lib/ld-linux.so.2
> #14 0xb79af299 in dlerror () from /lib/libdl.so.2
> #15 0xb79aed54 in dlopen () from /lib/libdl.so.2
> #16 0xb6ecca78 in apr_dso_load (res_handle=0x0, path=0x0,
> pool=0x8090c40) at dso.c:139
> #17 0xb6d3baa1 in Dll_JIT (this=0x80a8640,
>     dll_filename=0x80a8774
> "/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//libjitrino.so")

OK, what I see is you cannot load libjitrino.so, how unhappy you are:)

The trace looks suspicious since there is a good "dll_filename" to
load in Dll_JIT::Dll_JIT. "dll_filename" should be passed as the
second parameter /* path */ to apr_dso_load() AS_IS, with no change,
but that's not what happens, NULL is passed. I suspect those "memset"
and "apr_pool_create" to nullify our goody string.

Could you track what happens with "dll_filename" in Dll_JIT
(vmcore/src/jit/dll_jit.cpp:57), and why :)

AFAIR, you cannot put a breakpoint directly in constructor, so feel
free to add some unique function call at the beginning and break
there.

BTW, it is not like the original bug. Now you have a SIGSEGV, but
in older times it hung. Interesting..

-- 
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


Mime
View raw message