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 22:05:34 GMT

On Jan 26, 2007, at 4:54 PM, Gregory Shimansky wrote:

> Geir Magnusson Jr. wrote:
>> 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, the defaults on different systems are different. What you've  
> displayed is soft limit, try "ulimit -a -H". If you see that your  
> hard stack limit is unlimited, you can set your soft limit up to  
> that value, that is, make it unlimited as well. And then you can  
> have all the joys of unlimited stack including machine freeze  
> searching for more virtual memory.

What's what I was hinting at - someone is going to be surprised if  
SOE doesn't work on x86_64, and the VM just falls over.

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


Mime
View raw message