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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
