Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of pavel.n.afremov@gmail.com
 designates 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=ofxGZsXxQkSwcXdYHjoXoq0VXhrBVRC8sfFXKDQ5wGtMOr+n3axhc8lV9FcafeALXMuk1sN9hcO1AOLi2SzG8jwynuCyaJvyXe6LiaCe7YK4FnmuQZYTfw7/kGfitRwkOMhJ8yVq+zsDZMXO51a/IY8TN/ybfuWdQaV7TsU1Tj4=
Message-ID: <783bf8b0701250701p4e37b022v762109fcbd7a8903@mail.gmail.com>
Date: Thu, 25 Jan 2007 18:01:32 +0300
From: "Pavel Afremov" <pavel.n.afremov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm] stress.Stack causes a,
 "sigsegv in vm code" on a 2 cpu rhel4 box
In-Reply-To: <e79e5b390701250554p1c03bda6o771b24b6a457eda9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_30372_22121442.1169737292627"
References: <4dd1f3f00701101326r778199d7wcb4e0bc4b467c72c@mail.gmail.com>
	 <2DB88B29-5636-48A5-9979-897528D776CC@pobox.com>
	 <24AE9F7E-A694-424D-A265-A956F3180214@uiuc.edu>
	 <e79e5b390701112341n5ca0c132yaf95ba8fbfa3edcd@mail.gmail.com>
	 <eo80c3$rrs$1@sea.gmane.org>
	 <067A1063-199E-408F-9B41-F499AA92901C@pobox.com>
	 <eob9p5$mjj$1@sea.gmane.org>
	 <e79e5b390701150009q17acd20fx97272461803f1e7c@mail.gmail.com>
	 <783bf8b0701250527o556bc724o673ecab17bbb809f@mail.gmail.com>
	 <e79e5b390701250554p1c03bda6o771b24b6a457eda9@mail.gmail.com>

------=_Part_30372_22121442.1169737292627
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

SOE for x86_64 isn't required very mach, because this platform hasn't limit=
s
on stack size. The other case when this limits is set specially by ulimit =
=96s
command. For this configuration test should broke VM and should be excluded=
.
But for x86_64 ONLY!


On x86_32 it should works. Degradation on RHEL4 founded by Weldon should be
investigated.


BR
Pavel Afremov.

On 1/25/07, Elena Semukhina <elena.semukhina@gmail.com> wrote:
>
> On 1/25/07, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> >
> > SOE implementeation for x86_64 platform was not contributed due a bug i=
n
> > threading system. SOE for x86_32 should works on any platform.
> >
> > Weldon When did you notice that on your x86_32 machine? Did it works
> > before
> > or you didn't run tests on your RHEL4 machine before?
> >
> >
> >
> > I think that StackTest should be excluded. We should find changes which
> is
> > source of the crash.
>
>
> Pavel,
>
> StackTest, stress.Stack and exception.FinalizeStackTest are excluded for
> Linux x86_64 and *http://issues.apache.org/jira/browse/HARMONY-2972* has
> been filed to track this issue. Could you please add a comment to this
> issue?
>
> Besides, the overall picture of excluded smoke tests could be seen in the
> http://wiki.apache.org/harmony/DRLVMInternalTests page
>
> Elena
>
>
> > Thanks.
> >
> > Pavel Afremov.
> >
> >
> >
> >
> > On 1/15/07, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> > >
> > > On 1/14/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > >
> > > > 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 passed for me).
> > > > >>> I ran it on that platform and saw rather strange behavior. The
> > test
> > > is
> > > > >>> essentially the same as stress.Stack: both tests invoke a metho=
d
> > > > >>> recursively
> > > > >>> waiting for StackOverflowError. The difference is that the
> method
> > is
> > > > >>> void in
> > > > >>> StackTest and boolean in stress.Stack. Another difference is
> that
> > > > >>> StackTest
> > > > >>> should never fail: it detects both throwing StackOverflowError
> and
> > > not
> > > > >>> throwing it as normal situation. Doing that it passes even with
> > > > >>> 200000000
> > > > >>> iterations with no StackOverflowError (!) (JIT) while on RI it
> > gets
> > > > >>> StackOverflowError after 650000 iterations. On drlvm linux ia32
> it
> > > > gets
> > > > >>> exception after 8600 iterations. It also gets the exception in
> > > > >>> interpreter
> > > > >>> mode on em64t (about 2400 iterations).
> > > > >>> Can this be correct behavior?
> > > > >>
> > > > >> If you use SuSE9 on x86_64, then most likely it is because of
> > > > >> weirdness of SuSE9 installation. It has no hard or soft stack
> limit
> > > by
> > > > >> default (see ulimit -s). You can try to limit stack size like
> > ulimit
> > > > >> -s 8192 and then this test should not give too many iterations.
> If
> > > you
> > > > >> upgrade to SuSE10, you will see that it has default stack limit
> > 8192.
> > > > >>
> > > > >> The current implementation of SOE in drlvm is that it takes stac=
k
> > > size
> > > > >> from the system. If system has no limit, then stack has no limit
> as
> > > > >> well. It has been discussed in other threads about SOE that this
> is
> > > > >> not very good, but hasn't been fixed AFAIK.
> > > > >>
> > > > >
> > > > > I think that if we can find a way to have an "cononical
> environment"
> > > for
> > > > > linux that get set before running the tests, that would be useful=
.
> > > >
> > > > I agree. I think the easiest way would be to implement -Xss option
> for
> > > > drlvm and use it for those tests which actually depend on stack siz=
e
> > > > like StackTest and stress.Stack.
> > >
> > >
> > > This task is already declared at
> > > http://wiki.apache.org/harmony/CoreVmDevelopmentItems page.
> > > I think there should be also a default stack size value for the
> systems
> > > with
> > > unlimited stack size. The test shows that RI definitely limits stack
> > size
> > > on such systems.
> > >
> > > BTW, should we also change the test so that it fails after creating a
> > huge
> > > number of stack frames?
> > >
> > > Elena
> > >
> > >
> > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Elena
> > >
> > >
> >
> >
>
>
> --
> Thanks,
> Elena
>
>

------=_Part_30372_22121442.1169737292627--