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] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 26 Jan 2007 14:05:35 GMT
StackTest works for me on Fedora Core x86_32 Linux 2.6.15-27-686 #1 SMP.


BR
Pavel Afremov.


On 1/25/07, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
>  SOE for x86_64 isn't required very mach, because this platform hasn't
> limits on stack size. The other case when this limits is set specially by
> ulimit –s 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
> > in
> > > 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
> > method
> > > > > >>> 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
> > stack
> > > > 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
> > size
> > > > > 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
> >
> >
>

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