Hello
After new mode was chosen for kernel tests, they crash on win32. The
test which crashes is the same in all 3 modes: j.l.SystemExtensionTest.
I've found 2 types of failures. Exception is thrown with two different
status. It is STATUS_OBJECT_TYPE_MISMATCH (0xC024) or
Fedotov, Alexei A wrote:
Vladimir,
Yes, I can reproduce the issue with
org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest on
Windows 2003 server.
Unfortunately, all frames of the stack trace above the exception handler
are unrecognizable (JITted?)
You can try to evaluate
Hello
Today I've found a bug (HARMONY-2271) which lead down to APR
implementation of getenv function on windows. I've looked at the APR
page and found that there is a new release 1.2.7. In drlvm we still use
1.2.6.
While the bug which I've found was apparently fixed after 1.2.7 was
Hello Geir
I really didn't notice that it was assigned to you, I noticed it only in
JIRA notification. If you were working on it please assign it back to
yourself. I am just trying to help, you know.
--
Gregory
On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
Tatiana,
That's great! Feel free to file JIRA issues about new problems.
This is quite interesting that you haven't discovered
org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
failure using effectively the same
Correction below
Gregory Shimansky wrote:
On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
Tatiana,
That's great! Feel free to file JIRA issues about new problems.
This is quite interesting that you haven't discovered
Salikh Zakirov wrote:
Evgueni Brevnov wrote:
Agree! It seems like a mess for me as well. The most clean approach is
to return EXCEPTION_CONTINUE_SEARCH for any exception happened in a
native code.
I recently found out the reason why smoke test gc.LOS hangs DRLVM on Windows
XP, and it turned
On Sunday 26 November 2006 03:30 Geir Magnusson Jr. wrote:
1) Why add the SuspendDisabledChecker if not using it?
2) exactly where did you add the assertion? :)
It is a hidden assertion class :)
Look at the file vm/vmcore/include/suspend_checker.h. There are 2 classes
SuspendEnabledChecker
Weldon Washburn wrote:
On 11/25/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
A1) segfault occured
A2) grab system hwe lock and call vectored_exception_handler
A3) instantiate NullPointerException object
A4) set up throwing
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
On Sunday 26 November 2006 03:30 Geir Magnusson Jr. wrote:
1) Why add the SuspendDisabledChecker if not using it?
2) exactly where did you add the assertion? :)
It is a hidden
Geir Magnusson Jr. wrote:
Sorry? What were the recent changes?
Evgueni probably mean the patch in HARMONY-2320 which I've committed
yesterday. It is actually a change to *drlvm* Windows *exceptions*
handling. As far as I understand Linux signals are not touched yet.
Evgueni Brevnov
Salikh Zakirov wrote:
Alexey Varlamov wrote:
Gregory,
A couple of spotted issues in the change:
1) Portablity: code is ia32-specific due to unit32-casted assignments
to Registers fields. Why don't use POINTER_SIZE_INT or UDATA instead?
This is in ia32/nt_exception_filter.cpp, so no
Gregory Shimansky wrote:
2) It dropped support for vm.assert_dialog switch completely, which
is proved to be quite useful for various kinds of automated testing.
We even discussed recently that launcher lacks similar feature, and I
anticipate other developers will raise complains soon.
Despite
Vladimir Beliaev wrote:
Hello,
I experimented with DRLVM JIRA filtering to get an idea about current
issues. BTW, does anyone know the expression to find all DRLVM bugs
excepting ones containing [jit] in summary (I mean, help says that just
'NOT \[jit\]' in summary is not a valid expression)
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Gregory Shimansky wrote:
2) It dropped support for vm.assert_dialog switch completely, which
is proved to be quite useful for various kinds of automated testing.
We even discussed recently that launcher lacks similar feature, and I
anticipate
Alexey Varlamov wrote:
Anyway, if you don't mind, I'll try to change the launcher code to use
launcher.enable.crash.handler which should be true by default.
How about using -Xoption instead of -Doption?
I'm going to integrated HARMONY-1925 soon, which introduces
distinction between Java and
Oleg Khaschansky wrote:
I think we should fix this problem for all libraries loaded with
dlopen on linux (i.e. for all autogenerated linux native wrappers). As
far as I recall, this problem already appeared for liblcms and libXmu.
I'd suggest to wait until we know if we'll have a generator of
Weldon Washburn wrote:
Xiao Feng,
It would be great if you could publish something like a list of what tests
run. I tried to run build test on windowsxp 32 w/ gcv5. It looks like
all the [jvmti] tests using the JIT pass. For some yet to be discovered
reason, the test suite fails when it
Hello
Today while trying to run acceptance tests on x86_64 I've found that
kernel tests fail from the first test in pure Jitrino.OPT (-Xem:opt)
mode. I've tried running simple hello world application, and it does not
work any more. The NPE happens in class loader code before the main class.
to be instability. It is quite stably reproducible
in the same place. I'll try to find more details, like instruction which
causes SIGSEGV.
On 12/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Gregory Shimansky wrote:
Hello
Today while trying to run acceptance tests on x86_64 I've found
Vladimir Ivanov wrote:
The CC was also run on the SUSE 9 64 bit linux. The notification will be
Is there a reason to use SUSE9? It is more than 2 years old. Could you
use something more modern like at least SUSE10?
send to the [EMAIL PROTECTED] address from [EMAIL PROTECTED]
One more
Alexey Petrenko wrote:
2006/12/1, Gregory Shimansky [EMAIL PROTECTED]:
On Thursday 30 November 2006 17:21 Oleg Khaschansky wrote:
No, Sun links against X11 and ALSA and doesn't use dlopen. It doesn't
seem to be a problem for anyone. Why can't we?
Yes, I think we can do this with X11
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Alexey Petrenko wrote:
Don't you need to specify exact version of library you depend on?
It is up to distributions to care about the exact version of libraries
that they provide. When they build and test harmony with these
libraries
Weldon Washburn wrote:
On 11/30/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
Xiao Feng,
It would be great if you could publish something like a list of what
tests
run. I tried to run build test on windowsxp 32 w/ gcv5. It looks
like
all the [jvmti] tests using
libraries
instead of static ones. Do you use up to date revision?
Do you have all necessary devel packages installed? I think classlib
docs should list the packages that are necessary to build it.
On Oct 11, 2006, at 6:57 PM, Gregory Shimansky wrote:
On Wednesday 11 October 2006 05:28 Leo
Alexei Fedotov wrote:
Gregory, All,
I started looking into the compile.cpp file and found new ti callbacks
in compile_jit_a_method jit stub. I've got several questions.
DebugUtilsTI *ti = VM_Global_State::loader_env-TI;
if(ti-isEnabled() ti-is_single_step_enabled()
!method-is_native())
{
Alexei Fedotov wrote:
Gregory,
Thank you for explaining. As far as I unerstand writing to the thread
unsafe list is enough to cause segmentation fault on smp. You need to
update two fields, and this cannot be done atomically.
Writing to the list won't do any harm as long as the list is not
Geir Magnusson Jr. wrote:
The DRLVM suite...
So the question is... was 20-25 min the time you expected?
Mikhail Loenko wrote:
which tests did you run?
I ran Classlib tests on DRLVM in once fork mode. it took about 20-25
minutes
on each x86 and x86_64 on Linux
2006/12/9, Geir Magnusson Jr.
to and that's a cute bit
of code to use as an example.
If you have any questions, I'd really like to help with this.
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
The DRLVM suite...
So the question is... was 20-25 min the time you expected?
Mikhail Loenko wrote:
which tests did you run
. Actually I think the list should not be updated
at all to save the memory.
Does it make sense?
On 12/9/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Alexei Fedotov wrote:
Gregory,
Thank you for explaining. As far as I unerstand writing to the thread
unsafe list is enough to cause
fileset dir=${build.semi.dir
}/${component.as.path}/_bin includes=${component.deploy.filenames} /
/copy
/default
--
Gregory Shimansky, Intel Middleware Products Division
Stepan Mishura wrote:
On 12/11/06, Gregory Shimansky wrote:
Stepan Mishura wrote:
It looks like commit r485644 (Applied HARMONY-2505 [drlvm] Class file
parser
improvements) is a cause of classlib test failures. I'm testing it now.
If you see ClassFormatError like in HARMONY-2611
to include VM dirs. That's
the one thing I don't understand in cunit tests.
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Hello Geir
Looks like this commit broke all drlvm tests. I've fixed JVMTI tests,
but I
can't figure out how to fix cunit ones. Smoke and kernel are probably
broken
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
ok - I fixed and committed, and now am testing. I know that's
backwards, but I figure I didn't break it more :) I'll ping when I
think it's right.
Your fix helped on linux, but on windows cunit tests still can't find
HYTHR.dll although
If the tests still fail for you, could you give any details on what
platform, which tests and how they fail?
Alexey Petrenko wrote:
twice :)
2006/12/12, Evgueni Brevnov [EMAIL PROTECTED]:
Alexey,
Did you try to clean and rebuild? It helped to me.
Evgueni
On 12/12/06, Alexey Petrenko
I've seen the same problems with cunit tests on x86_64 SuSE10. Many of
them crashed in the same place because for some reason hythread_self()
returned NULL. On SuSE9 these tests work for me.
I didn't investigate the problem so far.
Vladimir Ivanov wrote:
CC on SUSE9 64 bit failed to run
Geir Magnusson Jr. wrote:
No one?
I think I've reproduced the same problem on ia32 fedora (on other
linuxes everything works ok). I'm trying to investigate. The problem is
in function GetSystemProperty in vm/vmi/src/vmi.cpp
146 vmiError JNICALL
147 GetSystemProperty(VMInterface
Geir Magnusson Jr. wrote:
I think it was r486200, by weldon...
em64t won't even compile now...
I fixed it a moment ago in 486251. Try to update.
Geir Magnusson Jr. wrote:
Now it's stopped building for me :
build.native.cpp:
[cc] 142 total files to be compiled.
[cc]
else had changed.
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
No one?
I think I've reproduced the same problem on ia32 fedora (on other
linuxes everything works ok). I'm trying to investigate. The problem
is in function GetSystemProperty in vm/vmi/src/vmi.cpp
146 vmiError JNICALL
On Wednesday 13 December 2006 00:26 Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
This must be from the recent properties refactoring...
I've found out the reason of the change. It is r486100 in classlib.
Previously there was no call to GetSystemProperty
(??:-1)
[junit] 19: ?? (??:-1)
[junit] end of stack trace
[junit] Tests FAILED
And something like this on windows...
SY, Alexey
P.S. I do not have latest Gregory's patch yet.
2006/12/13, Geir Magnusson Jr. [EMAIL PROTECTED]:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
On Wednesday 13 December 2006 00:26 Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
This must be from the recent properties refactoring...
I've found out the reason of the change. It is r486100 in classlib
Geir Magnusson Jr. wrote:
what mail list did you send it to?
dev@harmony.apache.org
It is in another branch of this same thread where Alexey sent his message :)
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
On Wednesday 13 December 2006 00:26 Geir
Geir Magnusson Jr. wrote:
I found it - comment below :
Gregory Shimansky wrote:
I've created a patch to classlib which fixes the problem with drlvm.
Now if you could test it with IBM VME, I'll commit it:
Index: modules/luni/src/main/native/luni/shared/luniglob.c
Alexey Petrenko wrote:
Gregory,
I've checked your patch on Windows with IBM VME and all unit tests are
passed.
Now I'm running unit tests on Linux... The run is not finished yet.
But there is no crashes :)
Thank you for checking. I think to avoid such cases in the future
changes to parts
Weldon Washburn wrote:
I did an svn update for both classlib and drlvm in the last 4 hours. I get
[junit] Test Breakpoint1.Breakpoint1 FAILED on my redhat linux 32-bit
box. Is anyone else seeing this problem?
It is probably a problem with drlvm initialization discussed in
[drlvm][em64t]
Alexey Petrenko wrote:
BTW, I got the strange message on DRLVM before and with the latest
Gregory's patch:
C:\Work\testsuild\win_ia32_msvc_release\deploy\jdk\jre\bin\java.exe
HelloWorld
Failed to import JNI NIO functions.
The warning appeared after your commit of HARMONT-1505 r486159. The
Oliver Deakin wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
I found it - comment below :
Gregory Shimansky wrote:
I've created a patch to classlib which fixes the problem with
drlvm. Now if you could test it with IBM VME, I'll commit it:
Index
Oliver Deakin wrote:
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Do we really have a problem? Or is it something else?
Last night, Gregory tested his fix, and I've build snapshots (r486417)
on x86 linux/win and x86_64 linux and spot checked with apps and such,
and things seem to work.
Tim Ellison wrote:
Alexey Varlamov wrote:
Is there any reason to distinguish these cases? I suppose no, then
returned NULL is fine.
Maybe we do, i.e. where there is no value -Dfoobar. So perhaps we
need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
the *valuePtr to NULL
Tim Ellison wrote:
Gregory Shimansky wrote:
Tim Ellison wrote:
Maybe we do, i.e. where there is no value -Dfoobar. So perhaps we
need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
the *valuePtr to NULL if there is no value; and returns a
VMI_ERROR_NOT_FOUND if the property
Alexey Petrenko wrote:
I think on windows in debug move the pdb files
for classlib libraries should be copied to deploy directory. This is not
done so far.
Create a JIRA :)
Ok I created HARMONY-2719.
To build release version of class lib please use the following command:
ant
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Tim Ellison wrote:
Gregory Shimansky wrote:
Tim Ellison wrote:
Maybe we do, i.e. where there is no value -Dfoobar. So perhaps we
need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
the *valuePtr to NULL
of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Gregory Shimansky, Intel Middleware Products Division
Alexey, the newly added test shutdown.ThreadInterrupt stably hangs for me on
windows 2003 server SP1 on P4 with HT. Can you verify this? The dead lock
appears on shutdown it seems, but I didn't investigate it.
For some reason running this test separately doesn't help, it hangs only in
batch
Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
I put another set of snapshots in
http://people.apache.org/~geirm/snapshots/
Due to problem w/ hotel network, the Windows JRE didn't make it, but
it's embedded in the JDK and HDK anyway :)
Give them a spin. I've haven't tested them at all
On Saturday 16 December 2006 01:20 Geir Magnusson Jr. wrote:
My personal view is that we should statically link this crap into the
package so that there's no prereqs - just get harmony, run harmony, and
be in harmony.
I think we should get the understanding about what we are going to provide
0x0076b63b.
Note, eclipse 3.1.1 and 3.2.0 started OK.
Could somebody reproduce/fix it?
thanks, Vladimir
--
Gregory Shimansky, Intel Middleware Products Division
Vladimir Ivanov wrote:
Currently my CC do the classlib tests run over the IBMVM on the WinXP and
SUSE 9 Linux. Is it OK? Or should I switch it off to reduce the
notifications flow? Now we receive 2 notifications for these runs - one
from
[EMAIL PROTECTED] and other from [EMAIL PROTECTED] It
Geir Magnusson Jr. wrote:
My fault then, sorry.
I wanted people to give a quick smoke test / review of the snapshots
before I put them up.
I've tried to use x86_64 build as the least stable one so far. I've ran
VM tests replacing jdk in deploy dir with the jdk binaries which you've
Ivanov, Alexey A wrote:
In default installation WinXP does not have this library in system32.
This library is installed by Visual Studio 2003 and may be installed by
other software which was compiled with Visual Studio 2003 (which is
v7.1). Visual Studio 2002 (v7.0) has msvc70.dll, if I remember
Xiao-Feng Li wrote:
All. It's good to see this discussion initiated. That's exactly what
we want. It would be a little frustrating to see our solution
committed without any response from the community. :-) Anyway, we
submitted GCv5 finalizer solution for three reasons:
1. We don't want GCv5
mentioned that if we some day support VS.NET we'll have to
check for both msvcr71.dll and msvcr80.dll.
Gregory Shimansky wrote:
Ivanov, Alexey A wrote:
In default installation WinXP does not have this library in system32.
This library is installed by Visual Studio 2003 and may be installed by
other
Egor Pasko wrote:
On the 0x245 day of Apache Harmony Geir Magnusson, Jr. wrote:
There's been some comment on the fact that I'm using GCC v4.x for the
em64t builds, requiring users of the snapshot to use libstdc++ v6.
Is this a real problem? Shouldn't we be using the newest major
version of
Evgueni Brevnov wrote:
On 12/21/06, Elena Semukhina [EMAIL PROTECTED] wrote:
On 12/21/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Naveen,
It is true, HARMONY-2817 is not intended to fix stress.Mix. There are
two different issues with stress.Sync stress.Mix. I'm looking at
stress.Sync
On Thursday 21 December 2006 17:23 Elena Semukhina wrote:
On 12/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
On 12/21/06, Elena Semukhina [EMAIL PROTECTED] wrote:
On 12/21/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Naveen,
It is true, HARMONY-2817
On Monday 18 December 2006 18:37 Gregory Shimansky wrote:
Alexey Varlamov wrote:
2006/12/15, Gregory Shimansky [EMAIL PROTECTED]:
Alexey, the newly added test shutdown.ThreadInterrupt stably hangs for
me on
windows 2003 server SP1 on P4 with HT. Can you verify this? The dead
lock
2006 01:35 Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
The DRLVM suite...
So the question is... was 20-25 min the time you expected?
Mikhail Loenko wrote:
which tests did you run?
I ran Classlib tests on DRLVM in once fork mode. it took about 20-25
minutes
on each x86
On Saturday 23 December 2006 04:09 Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
I was not aware that drlvm didn't generate MethodEnter/Exit events for
native methods when I wrote this email. Now after applying HARMONY-2828
which fills this gap I've rerun my test agent and the top10
;Ljava/util/Map;Ljava/lang/String;)V
and
Ljava/util/jar/InitManifest;.nextChunk(Ljava/io/InputStream;Ljava/util/List;)
[B. I am afraid the manifest parsing code has to be changed to improve its
performance.
[1] http://people.apache.org/~gshimansky/methodee-stack.cpp
2006/12/23, Gregory Shimansky
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
Very interesting. Please tell me if the following is correct. Without
WBS, finalizing objects falls further and further behind because
finalization thread(s) are unable to grab enough of the CPU(s) to keep up.
Instead of increasing the
On Sunday 24 December 2006 23:01 Gregory Shimansky wrote:
On Saturday 23 December 2006 20:48 Mikhail Loenko wrote:
Can you publish most common stacks for the
157114 Ljava/io/ByteArrayOutputStream;.write(I)V
Yes I've been going to do this for some time already and now that you've
asked, I
Elena Semukhina wrote:
On 12/22/06, Elena Semukhina [EMAIL PROTECTED] wrote:
On 12/22/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 21 December 2006 17:23 Elena Semukhina wrote:
On 12/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
On 12/21
is
Sun's. So there is a valid use case for changing this property, probably for
other java.vm.* too.
I think I'll close HARMONY-2544 as invalid. Reopen it if you disagree.
Thanks.
Ivan
On 12/15/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
I could argue with Pavel that we have to have read
Weldon Washburn wrote:
On 12/24/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
Very interesting. Please tell me if the following is correct. Without
WBS, finalizing objects falls further and further behind because
finalization thread
Geir Magnusson Jr. wrote:
On Dec 28, 2006, at 12:54 AM, Geir Magnusson Jr. wrote:
I've been thinking a little bit about our alert messages, and
1) I think that each system that's submitting should have an assigned
ID, so it's easy to figure out who is what. It can be as easy as
On Thursday 04 January 2007 06:03 Weldon Washburn wrote:
I am observing intermittant failures in stress.Mix. It works fine when run
at the command line and fails when run under build test. I am now also
seeing intermittant failures in stress.Sync and stress.Thread.
What has changed is that
On Monday 08 January 2007 06:25 Peter Donald wrote:
On 1/8/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I use SVK to do things like this almost everyday and it works like a
charm. I even use SVK to do changes on repos I have write access so
that the granularity of main repo commit is
Elena Semukhina wrote:
It was me who removed stress.Mix from the exclude lists together with some
more tests because all they passed for me even when running many times on
Windows 2003, SUSE9 linux ia32, and SUSE9 linux em64t. It was at the end of
November.
CC started failing intermittently on
Geir Magnusson Jr. wrote:
I am not sure that we need to do something about this. The default
initial
stack size on Windows is 1M,
Yikes! There's our problem on windows...
The same OOME is thrown on Linux as well, but I am not sure if it
happens because of reaching virtual space limit or
Geir Magnusson Jr. wrote:
I think the same problem may happen on Linux because it spills out
OOMEs on Ubuntu as well.
If somehow test doesn't crash on failed mallocs and gets to the
shutdown stage and hangs with 2 or more dead locked threads. So far I
didn't quite understand how they lock
Tim Ellison wrote:
I'm going for the record of resurrecting the oldest thread ;-)
Having this additional signal handler in the launcher is causing me pain
too, so unless there are objections now I'm going to go ahead and
disable it by default, and have an option to enable it for those that
On Wednesday 10 January 2007 21:40 Naveen Neelakantam wrote:
On Jan 10, 2007, at 12:02 PM, Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
In the past, we've talked about what versions of GCC we will
consider as our supported toolchain. We noted that it's useful
to keep using other
Thorbjørn Ravn Andersen wrote:
Gregory Shimansky skrev den 10-01-2007 19:02:
I am surprised too. I tried to push moving to gcc 4.x because I use it
on all systems and we've had cases when code which compiles on 3.x
failed to compiled on 4.x because of more strict syntax checks.
Does
Alexey Petrenko wrote:
Guys,
I can not find libjpeg.a on my newly installed Fedora Core 6 box :(
Both (libjpeg-6b-37 and libjpeg-devel-6b-37) packages are installed.
Header files are found but library not...
I've checked packages themself but with they do not include this library...
Does
Geir Magnusson Jr. wrote:
On Jan 10, 2007, at 9:00 AM, Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
I think the same problem may happen on Linux because it spills out
OOMEs on Ubuntu as well.
If somehow test doesn't crash on failed mallocs and gets to the
shutdown stage and hangs
Weldon Washburn wrote:
On 1/11/07, Salikh Zakirov [EMAIL PROTECTED] wrote:
2)
Why not simply hard code DRLVM to throw an OOME whenever there
are
more than
1K threads running? I think Rana first suggested this approach.
My guess
is that 1K threads is good enough to run lots
Elena Semukhina wrote:
On 1/12/07, Naveen Neelakantam [EMAIL PROTECTED] wrote:
On Jan 11, 2007, at 12:28 PM, Geir Magnusson Jr. wrote:
On Jan 11, 2007, at 9:19 AM, Weldon Washburn wrote:
On 1/11/07, Tim Ellison [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
This actually brings up
Alexey Varlamov wrote:
2007/1/12, Salikh Zakirov [EMAIL PROTECTED]:
2007/1/11, Gregory Shimansky [EMAIL PROTECTED]:
Another reason for hanging threads is that they wait in
Thread.start().
When a new thread is started, it has to notify a lock object, in order
to signal the parent thread
Geir Magnusson Jr. wrote:
On Jan 12, 2007, at 7:53 AM, Gregory Shimansky wrote:
Elena Semukhina wrote:
I tried StackTest in jitrino debug mode on both SUSE9 linux 2 CPU
ia32 and
em64t machines. It passed. It is now excluded for linux x86_64 (probably
Geir has excluded it because it always
Alexei Zakharov wrote:
Hi all,
I gratefully like to announce that I was successful in building and
running Harmony on newly installed Debian stable Linux system. As far
as I remember nobody has tried to build on Debian before (I may be
wrong of course).
However there were some tricks I'd like
Vladimir Ivanov wrote:
Currently the eclipse 3.1.1 failed to start on lnx_em64t_gcc_debug build
with message:
drlvm/trunk/build/lnx_em64t_gcc_debug/deploy/jdk/jre/bin/java -cp
/export/users/viv/eclipse3.1.1/startup.jar -Dosgi.install.area=eclipse3.1.1
org.eclipse.core.launcher.Main -ws gtk os
Ivan Popov wrote:
I'd like to discuss the problem with Eclipse TPTP profiler working
with DRLVM, which is described in HARMONY-2905 [1]. The problem is
that verifier in DRLVM rejects class instrumented by TPTP profiler.
TPTP profiler instruments class bytecodes by enclosing each method
call
Hello
Today while investigating the bug in HARMONY-2975 it appeared that
eclipse doesn't start on 64-bit Linux because os.arch property value is
em64t. The property is set in DRLVM source. Eclipse doesn't recognize
this architecture and failed to load SWT library. When this property
value is
of mentioning vendor specific
identifiers, so that all functions, interfaces and constants could be
reused in easily in any other code.
(and I thought that em64t was intel shorthand for what AMD calls
amd64 which is x86_64)
Yes it is true.
On Jan 23, 2007, at 8:10 AM, Gregory Shimansky wrote
On Tuesday 23 January 2007 22:38 Geir Magnusson Jr. wrote:
On Jan 23, 2007, at 12:00 PM, Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
+1
(I thought we'd agreed on this - there were a few remaining cases,
I thought.)
I've grepped the sources and found very many places with em64t
Leo Li wrote:
Hi, all:
With the progress of Harmony project, I think, performance is gradually
becoming an important feature for our real customers. Besides the stability
and compatibility, users would incline to choose the one with higher
speed. Aside from VM, classlib itself also plays a
[+] +1 Accept this contribution
Geir Magnusson Jr. wrote:
We now have all requisite paperwork in place for
http://issues.apache.org/jira/browse/HARMONY-2918, so lets vote to accept :
[ ] +1 Accept this contribution
[ ] -1 Reject because...
As usual, 3 days unless someone complains they need
.
Pavel Afremov.
On 1/15/07, Elena Semukhina [EMAIL PROTECTED] wrote:
On 1/14/07, Gregory Shimansky [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
On Jan 12, 2007, at 7:53 AM, Gregory Shimansky wrote:
Elena Semukhina wrote:
I tried StackTest
Geir Magnusson Jr. wrote:
On Jan 26, 2007, at 4:54 PM, Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
What do you mean, the platform doesn't have limits on stack size?
[EMAIL PROTECTED]:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
max
1 - 100 of 466 matches
Mail list logo
