harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 26 Jan 2007 19:23:26 GMT
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 don't know the answer to your question.  I plan to do an svn update soon
and rerun all the tests to see if stress.Stack is still a problem.

I think that StackTest should be excluded. We should find changes which is
> source of the crash.
>
>
>
> 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
> >
> >
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

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