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 Thu, 25 Jan 2007 13:27:04 GMT
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.



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
>
>

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