harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Date Tue, 07 Nov 2006 10:40:34 GMT
Hello.

Could you be so kind to check
*HARMONY-2018*<https://issues.apache.org/jira/browse/HARMONY-2018>
before start fixing and discussing this bug,  please?

I reported it and provided a fix a week ago.



Thanks.

Pavel Afremov.

On 11/5/06, Fedotov, Alexei A <alexei.a.fedotov@intel.com> wrote:
>
> Rana, Pavel (Afremov), All,
>
> Geir's comment on r443504 (fix for
> http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
> bit support, JVMTI improvements) reads:
>
> > 1) Stack overflow exception stuff is broken.  I had to remove the
> assert
> >    in signals_ia32.cpp line 336.  Rana knows and will look.  I also
> >    disabled the StackTest.
>
> I have noticed that the patch added a new function
> exn_raise_by_name_internal which fails on the first invocation checking
> an assertion about thread state, see
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> crashes DRLVM.
>
> I also have noticed that this function is called to create
> java.lang.StackOverflowError.
>
> Could you help me to understand the current status of the problem?
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
> >-----Original Message-----
> >From: Rana Dasgupta [mailto:rdasgupt@gmail.com]
> >Sent: Wednesday, October 18, 2006 4:27 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> is
> >fixed
> >
> >I fixed the StackOverflow functionality problem by going back and
> mapping
> >all pages ( guard, alternate stack ) meticulously before trying to
> protect
> >them. I think we should have done this in the first place.  I also
> cleaned
> >up the previous initialization workarounds and asserts Geir and I had
> >discussed on the JIRA. The Stacktest and all other stack related tests
> now
> >pass.
> >
> >I'll submit the patch against 1786 in the next few hours after running
> >acceptance tests.
> >
> >Rana
> >
> >
> >
> >> On 10/16/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On 10/16/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> >> > >
> >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> >> > > >> I tried to put some back.  StackTest still doesn't work.
 It's
> >hard
> >> > > to
> >> > > >> believe...   so I gave up and just kept going :)
> >> > >
> >> > > >I wonder if the test or the implementation are wrong. Maybe
> someone
> >> > > who added
> >> > > >the test initially could know the answer.
> >> >
> >> >
> >> >
> >> >  There is nothing wrong with the stacktest test itself. The
> >> > > implementation is not quite 100%complete( I think ), but has
> enough
> >> > > functionality and the test passes on Windows. On Linux, it fails.
> I
> >am not
> >> > > sure if this is a regression, or if this ever worked. There is a
> JIRA
> >issue
> >> > > 1786. In summary, memory protection setup for the guard page
> fails on
> >the
> >> > > main thread(only). So the guard does not work and the overflow is
> not
> >> > > detected.
> >> >
> >> >
> >> >    mprotect fails with an ENOMEM which is either a mapping failure
> or a
> >> > kernel failure. mprotect() has some known flakiness it seems, as
> per
> >> > literature.
> >> >
> >> >   The basic implementation on Linux is sound. There are secondary
> >design
> >> > issues,but we can only get to them later after we have figured out
> why
> >the
> >> > guard setup fails on the main thread.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >>
> >>
> >>
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message