29 Sep 2006 14:43:03 +0700, Egor Pasko <[EMAIL PROTECTED]>:
On the 0x1F3 day of Apache Harmony Armand Navabi wrote:
> > 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 :)
>
> Here is what happens:
>
> vm_load_jit (file_name=0x80a8774
> "/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//l
> ibjitrino.so", handle=0xbfc3fc2c) at
> /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp:6
> 28
> 628 Dll_JIT* jit = new Dll_JIT(file_name);
> (gdb) s
> Dll_JIT (this=0x80a8640, dll_filename=0x80a8774
> "/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//l
> ibjitrino.so")
> at
> /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/jit/dll_jit.cpp:56
> 56 {
> (gdb) p dll_filename
> $2 = 0x80a8774
> "/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//l
> ibjitrino.so"
> (gdb) n
> 59 memset((void *) &jit_flags, 0, sizeof(JIT_Flags));
> (gdb) n
> 60 apr_pool_create(&pool, 0);
> (gdb) n
> 62 if ((stat = apr_dso_load(&handle, dll_filename, pool)) !=
> APR_SUCCESS)
> (gdb) p dll_filename
> $3 = 0x80a8774
> "/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//l
> ibjitrino.so"
> (gdb) s
> apr_dso_load (res_handle=0x102, path=0x102 <Address 0x102 out of bounds>,
> pool=0x8090c40) at dso.c:139
> 139 os_handle = dlopen(path, flags);
> Current language: auto; currently c
>
> Notice that memset and apr_pool_create to not nullify dll_filename. At line
> 62 of dll_jit.cpp, the value of dll_filename is correct. But then it is
> passed to apr_dso_load, and when I step into apr_dso_load notice that
> path=0x102 <Address 0x102 out of bounds>.
...calling convention to APR... who is an expert in this?
here is what I found in apr.h:
/**
* The public APR functions are declared with APR_DECLARE(), so they may
* use the most appropriate calling convention. Public APR functions with
* variable arguments must use APR_DECLARE_NONSTD().
I'm not an expert, but AFAIU these macros are essentially for
switching between static/dynamic linkage with APR binaries.
apr_dso_load is declared like this:
APR_DECLARE(apr_status_t) apr_dso_load(apr_dso_handle_t **res_handle,
const char *path, apr_pool_t *pool)
does not give any clue to me :)
That's right, dso_load is ordinary function thus follow common
convention. Nothing more here.
My current assumption is that APR configured itself somewhat
incorrectly on your system.
Hmm, DRLVM build enforces static linking with APR artifacts built
alongside the VM - it does not use any pre-installed APR. And I hardly
think APR configure fails here...
Nevertheless, Armand, maybe it worths trying a standalone APR test?
Either simple dso_load scenario, or even APR unit tests (these are
bundled with APR sources, just look for README).
--
Regards,
Alexey
--
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]
