harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] stress.Stack causes a, "sigsegv in vm code" on a 2 cpu rhel4 box
Date Fri, 26 Jan 2007 21:14:59 GMT
What do you mean, "the platform doesn't have limits on stack size"?

geir@harmony-em64t:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) unlimited
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

geir

On Jan 26, 2007, at 1:34 PM, Rana Dasgupta wrote:

> Pavel is right, the urgency of SOE for x86_64 is not high.
>
> StackTest works for me on RHEL 4, Update 3 Linux 32 bit.
>
>
> On 1/25/07, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>>
>> SOE for x86_64 isn't required very mach, because this platform hasn't
>> limits
>> on stack size. The other case when this limits is set specially by  
>> ulimit
>> –s
>> command. For this configuration test should broke VM and should be
>> excluded.
>> But for x86_64 ONLY!
>>
>>
>>
>> On x86_32 it should works. Degradation on RHEL4 founded by Weldon  
>> should
>> be
>> investigated.
>>
>>
>> BR
>> Pavel Afremov.
>>
>> On 1/25/07, Elena Semukhina <elena.semukhina@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 think that StackTest should be excluded. We should find changes
>> which
>> > is
>> > > source of the crash.
>> >
>> >
>> > Pavel,
>> >
>> > StackTest, stress.Stack and exception.FinalizeStackTest are  
>> excluded for
>> > Linux x86_64 and *http://issues.apache.org/jira/browse/ 
>> HARMONY-2972* has
>> > been filed to track this issue. Could you please add a comment  
>> to this
>> > issue?
>> >
>> > Besides, the overall picture of excluded smoke tests could be  
>> seen in
>> the
>> > http://wiki.apache.org/harmony/DRLVMInternalTests page
>> >
>> > Elena
>> >
>> >
>> > > 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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Thanks,
>> > Elena
>> >
>> >
>>
>>


Mime
View raw message