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 Mon, 29 Jan 2007 11:06:38 GMT
I reproduced following crash of build system after running of stress.Stack:



     [echo] Running test : stress.Stack

     [echo]  PASSED : stress.Stack



BUILD FAILED

/nfs/ims/proj/drl/mrt1/users/pnafremo/work/JNIOpt/drlvm/build/make/build.xml:398:
The following error occurred while executing this line:

/nfs/ims/proj/drl/mrt1/users/pnafremo/work/JNIOpt/drlvm/build/make/build_component.xml:72:
The following error occurred while executing this line:

/nfs/ims/proj/drl/mrt1/users/pnafremo/work/JNIOpt/drlvm/build/lnx_ia32_gcc_debug/semis/build/targets/smoke.test.xml:80:
The following error occurred while executing this line:

/nfs/ims/proj/drl/mrt1/users/pnafremo/work/JNIOpt/drlvm/build/lnx_ia32_gcc_debug/semis/build/targets/smoke.test.xml:136:
The following error occurred while executing this line:

/nfs/ims/proj/drl/mrt1/users/pnafremo/work/JNIOpt/drlvm/build/lnx_ia32_gcc_debug/semis/build/targets/smoke.test.xml:171:
java.lang.OutOfMemoryError: Java heap space



The source of the crash can be heavy printing in stress.Stack test, and this
crash has no relation to StackOverflowError support implementation.

Weldon, did you have the same crash?



Thanks

Pavel Afremov.


On 1/26/07, Weldon Washburn <weldonwjw@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 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