gards,
Alexei Fedotov,
Intel Middleware Products Division
>-Original Message-
>From: Artem Aliev [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, September 20, 2006 8:34 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [DRLVM] Thread Manager jvmti related issues fixes (was:
R
On 9/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Sep 21, 2006, at 6:48 AM, Elena Semukhina wrote:
> On 9/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>
>> On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> >
>> > Looking at ThreadTest failures I see that all 1421-related
Geir Magnusson Jr. wrote:
> On Sep 21, 2006, at 6:48 AM, Elena Semukhina wrote:
>
>> On 9/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>>
>>> On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>>> >
>>> > Looking at ThreadTest failures I see that all 1421-related failures
>>> > disappear.
On Sep 21, 2006, at 6:48 AM, Elena Semukhina wrote:
On 9/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> Looking at ThreadTest failures I see that all 1421-related failures
> disappear. But there are 3 new failures which I've never se
What are the two launcher related failures?
On Sep 21, 2006, at 4:21 AM, Elena Semukhina wrote:
Looking at ThreadTest failures I see that all 1421-related failures
disappear. But there are 3 new failures which I've never seen
before. Two of
them actually relate to "using the launcher" problem
On 9/21/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>
> Looking at ThreadTest failures I see that all 1421-related failures
> disappear. But there are 3 new failures which I've never seen before.
Two
> of
> them actually relate to "using th
On 9/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
Looking at ThreadTest failures I see that all 1421-related failures
disappear. But there are 3 new failures which I've never seen before. Two
of
them actually relate to "using the launcher" problems,
Is it possible to give more details ab
Looking at ThreadTest failures I see that all 1421-related failures
disappear. But there are 3 new failures which I've never seen before. Two of
them actually relate to "using the launcher" problems, but the third one
deserves a special investigation.
The problem is that Thread.currentThread().is
I'm not paying much attention to the kernel tests these days while we
sort out the main problems.
I do think that once we sort out the "using the launcher" problems,
and get the patch backlog applied, we really should go after all of
these broken tests
We also need to refractor the test f
On 9/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
patch applied, JIRA closed
Good. I was just about to suggest the very same thing. I applied both of
the 1421 patches and a substantial number of tests now run on windows. At
this time I see only the below test failures. I commented
patch applied, JIRA closed
geir
On Sep 20, 2006, at 1:17 PM, Ivan Volosyuk wrote:
Artem, your fix works for me.
Digging in the implementation I have got your idea. I like the fix :)
--
Ivan
On 9/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
I have traced down problem to implementation of t
Artem, your fix works for me.
Digging in the implementation I have got your idea. I like the fix :)
--
Ivan
On 9/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
I have traced down problem to implementation of thin locks.
Here is what I get, look at the stack:
hythread_suspend_other()
unreser
I have traced down problem to implementation of thin locks.
Here is what I get, look at the stack:
hythread_suspend_other()
unreserve_lock()
hythread_thin_monitor_try_enter()
All this code is executed suspend disabled mode and is not a safe point.
Suppose two threads want to unreserve lock o
Ivan,
We do a lot for this cyclic suspend problem,
I hope we does it right. I think the problem is in typo that was done
in last patch.
Fix attached. Could you please verify it.
I will also attach it to the HARMONY-1421
we already try to has global lock for s
I have found one fundamental design flow in implementation of:
hythread_suspend_other()
hythread_suspend_all()
The functions should be called only from suspend enabled state,
because the should be itself a valid point of suspension to prevent
deadlocks. The other problem is: hythread_suspend_
Artem, it looks like two thread mutually suspended each other.
This is only reproducible when jvmti.patch from the JIRA is applied.
--
Ivan
On 9/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
I have reproduced the problem with the stack trace same as reported by Gregory.
Here is the stack trace
16 matches
Mail list logo
