harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Date Mon, 06 Nov 2006 15:12:55 GMT
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