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 21:54:39 GMT
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.

> 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