harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Mon, 29 Jan 2007 12:43:18 GMT
Pavel Afremov wrote:
> 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

It doesn't look like a crash to me. It looks more like ant went out of 
heap space. Try to add -Xms256m -Xmx512m to ANT_OPTS. For me running 
smoke tests with these options works fine.

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


-- 
Gregory


Mime
View raw message