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().
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 :)
My current assumption is that APR configured itself somewhat
incorrectly on your system.
--
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]
