harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Mon, 29 Jan 2007 13:56:49 GMT
On 1/29/07, Pavel Afremov <pavel.n.afremov@gmail.com> 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
>
>
>
> The source of the crash can be heavy printing in stress.Stack test, and
> this
> crash has no relation to StackOverflowError support implementation.


BTW, I removed printing in this test and got segmentation fault:

SIGSEGV in VM code.
Stack trace:
        1: locktable_get_fat_monitor
(/nfs/ins/proj/drl/coreapi/esemukhi/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:655)
        2: hythread_thin_monitor_try_enter
(/nfs/ins/proj/drl/coreapi/esemukhi/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:310)
        3: IP is 0x416A25BD <native code>
        4: ?? (??:-1)
<end of stack trace>
Segmentation fault

I filed https://issues.apache.org/jira/browse/HARMONY-3010 to trackthe
issue.

Elena


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





-- 
Thanks,
Elena

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