There are clean sources unzipped at
drlvm\build\pre-copied\lnx\APR\apr-1.2.6\
and (slighly) patched ones (actually used by VM build) at
drlvm\build\lnx_ia32_gcc_debug\semis\extra\apr\src\
See README.dev in those location on how to run tests.
Or - just a wild thought - hack
Alexey,
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
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
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()
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.
[EMAIL PROTECTED]
yes - add the bin directory and the default directory to your
LD_LIBRARY_PATH - the launcher will decide that it doesn't need to do
the execv() and will skip it...
geir
On Sep 28, 2006, at 2:31 AM, Armand Navabi wrote:
I followed your suggestions below and made everything build in debug
/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre
...
Armand
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 2:39 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] [launcher] Executable hangs
yes - add the bin
Looks like a progress :)
On the 0x1F2 day of Apache Harmony Armand Navabi wrote:
That did not fix it for me. I thought I had both the bin directory and the
default directory in my LD_LIBRARY_PATH. I just ran it again to make sure,
and it still seems to get lost on execv(). Is there
On Sep 28, 2006, at 3:41 AM, Egor Pasko wrote:
Looks like a progress :)
On the 0x1F2 day of Apache Harmony Armand Navabi wrote:
That did not fix it for me. I thought I had both the bin
directory and the
default directory in my LD_LIBRARY_PATH. I just ran it again to
make sure,
and it
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:
1047if (newPathToAdd[i] != NULL strstr(oldPath,
newPathToAdd[i]) != 0) {
(gdb) p newPathToAdd[i]
$2 = 0x8067ae8
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:
1047if (newPathToAdd[i] != NULL strstr(oldPath,
newPathToAdd[i]) !=
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
Armand Navabi wrote:
What is the kernel version BTW? There could be some issues with
2.4.x, currently everybody works with 2.6.x
The kernel version is 2.6.17.8.
concerning hythread_exit .. Did you resolve it already? I see the
symbol _undefined_ too (and no definition of the symbol in
On the 0x1F1 day of Apache Harmony Salikh Zakirov wrote:
Armand Navabi wrote:
What is the kernel version BTW? There could be some issues with
2.4.x, currently everybody works with 2.6.x
The kernel version is 2.6.17.8.
concerning hythread_exit .. Did you resolve it already? I see
Salikh Zakirov wrote:
Armand Navabi wrote:
../java: relocation error:
/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so
: symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so
with link time reference
The error DRLVM's version of libhythr.so in
Egor Pasko wrote:
hm, looks stange to me. I see a def of hythread_exit() in
hythread.c:1530. Why it is not in libhythr.so is a mystery ;)
No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so,
but DRLVM insists on using its own, different, libhythr.so.
On the 0x1F0 day of Apache Harmony Armand Navabi wrote:
What is the kernel version BTW? There could be some issues with
2.4.x, currently everybody works with 2.6.x
The kernel version is 2.6.17.8.
concerning hythread_exit .. Did you resolve it already? I see the
symbol _undefined_ too
On the 0x1F1 day of Apache Harmony Salikh Zakirov wrote:
Egor Pasko wrote:
hm, looks stange to me. I see a def of hythread_exit() in
hythread.c:1530. Why it is not in libhythr.so is a mystery ;)
No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so,
but DRLVM insists on using
FWIW, Thanks for sticking with us on this.
I'm sure we'll find it.
geir
On Sep 27, 2006, at 1:35 AM, Armand Navabi wrote:
Gregory Shimansky wrote:
I think not. DRLVM needs its own threading library. The reason is
discussed in
a separate thread thread library - let there be one. I am not
applied. thx
On Sep 27, 2006, at 6:36 AM, Salikh Zakirov wrote:
Salikh Zakirov wrote:
Armand Navabi wrote:
../java: relocation error:
/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/
libhyprt..so
: symbol hythread_exit, version HYTHR_0.1 not defined in file
libhythr.so
Hmm never saw it hanging at this point. It looks like a java class loader
starts on loading a j.l.Thread class and somehow deadlocks or waits for
something. I would try to get a stack trace in the first place, evaluating
st_print() in debugger but it doesn't always work correctly.
Can anyone
This did not seem to solve the problem. It does not successfully put a
break in main.c (says no source file main.c).
[EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ gdb
./java
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the
On the 0x1F2 day of Apache Harmony Armand Navabi wrote:
This did not seem to solve the problem. It does not successfully put a
break in main.c (says no source file main.c).
Oops, some day I made everything build in debug mode locally. And
forgot about it. Currently there is no option for that.
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
What is the kernel version BTW? There could be some issues with
2.4.x, currently everybody works with 2.6.x
concerning hythread_exit .. Did you resolve it already? I see the
symbol _undefined_ too (and no definition of the symbol in hythread.so
or any other lib, although sources are fine,
On Tuesday 26 September 2006 20:24 Armand Navabi wrote:
What is the kernel version BTW? There could be some issues with
2.4.x, currently everybody works with 2.6.x
The kernel version is 2.6.17.8.
I am running Gentoo too and I confirm that 2.6.17-r8 is the latest stable
kernel for Gentoo.
26 matches
Mail list logo
