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:39:40 GMT

On Jan 26, 2007, at 5:26 PM, Gregory Shimansky wrote:

> Geir Magnusson Jr. wrote:
>> 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.
>
> Ok so we agree on this topic (not the first time it seems) on that  
> there should be a default stack limit set to the default value of  
> the -Xss of stack limit option.

YES! :)

>
> This stack length limit discussion is getting too long. I am going  
> to see just how hard it is to implement -Xss in DRLVM with a  
> default to 8192Mb.

Clearly it's really late at night for you, and you worked hard this  
week....

Are you really suggesting a stack size of 8 gigabytes?

I'd suggest something like 512k, which is what the RI uses, I think.

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


Mime
View raw message