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:48:34 GMT
Rana,

Everything is correct in you description, but it looks like that *
HARMONY-2018* <https://issues.apache.org/jira/browse/HARMONY-2018> should
fix described bug. I think Alexei will have a chance to check it.



Thank you.

Pavel Afremov.


On 11/6/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Alexei,
>   The1363 submission added  functionality for lazy exception support, for
> exceptions in the VM code. exn_raise_by_name_internal was such a function.
> This may not be bug free ( as is true of any code ) and we need to check
> out
> 2070. I will take a look, as should Pavel.
>   I think that while committing 1363, StackTest failed and there were
> other
> asserts, which Geir disabled to not block the large submission. This is
> not
> really anything to do with lazy exceptions. This is an issue where parts
> of
> the main thread's stack virtual memory are unmapped on Linux. I later
> added
> a fix for this. The two issues are orthogonal to each other.
>
> Rana
>
>
>
> 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