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 Fri, 26 Jan 2007 22:26:55 GMT
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.

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.

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