Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Gregory Shimansky <gshimansky@gmail.com>
Subject: Re: [drlvm][em64t] build fails
Date: Thu, 16 Nov 2006 01:36:45 +0300
Lines: 79
Message-ID: <ejg4pl$3ti$1@sea.gmane.org>
References: <4554E6B2.7090001@apache.org>
	 <200611110153.19120.gshimansky@gmail.com>
	 <e0f125db0611101536y635d7f81lfe5af4ef4278424a@mail.gmail.com>
	 <200611110312.50644.gshimansky@gmail.com>
 <eja3pq$srf$1@sea.gmane.org>	 <783bf8b0611131123h3a881a4bvdfc64e156af1c4c6@mail.gmail.com>
	 <ejagrg$khk$1@sea.gmane.org>
 <783bf8b0611140856n3131b772p32a26fcde68c16e3@mail.gmail.com>
 <ejd1qc$v1b$1@sea.gmane.org> <455A5E1D.5040300@pobox.com>
 <ejf0p8$s3f$1@sea.gmane.org> <455B9354.1070200@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
In-Reply-To: <455B9354.1070200@pobox.com>
Sender: news <news@sea.gmane.org>

Geir Magnusson Jr. wrote:
> 
> 
> Gregory Shimansky wrote:
>> Geir Magnusson Jr. wrote:
>>>
>>>
>>> Gregory Shimansky wrote:
>>>> Pavel Afremov wrote:
>>>>> On 11/13/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>>>>>
>>>>>> So what is the point to have a test which would pass either way? 
>>>>>> Check
>>>>>> that it doesn't crash the VM, is it the only purpose for it?
>>>>>>
>>>>> I think yes. It should check that test doesn't crash VM if stack 
>>>>> size isn't
>>>>> enough.
>>>>
>>>> But we wouldn't know that SOE has happened or not if test passes 
>>>> even when SOE was not thrown.
>>>>
>>>> It seems like SuSE9 is the only existing distribution which doesn't 
>>>> limit stack size on 64-bit architectures. SuSE10 has this limit and 
>>>> Gentoo has it too. Should we care that this test fails on SuSE9 when 
>>>> it passes on all other platforms and SOE is known to be thrown?
>>>
>>> How could there be no limit to stack size??
>>
>> Well there is no stack limit imposed by the OS on SuSE9. Maybe it is 
>> specific to this version because on SuSE10 there is a normal limit of 
>> 8Mb. But when I run ulimit -a on SuSE9 I see this:
>>
>> core file size        (blocks, -c) unlimited
>> data seg size         (kbytes, -d) unlimited
>> file size             (blocks, -f) unlimited
>> max locked memory     (kbytes, -l) unlimited
>> max memory size       (kbytes, -m) unlimited
>> open files                    (-n) 4096
>> pipe size          (512 bytes, -p) 8
>> stack size            (kbytes, -s) unlimited
>> cpu time             (seconds, -t) unlimited
>> max user processes            (-u) 40960
>> virtual memory        (kbytes, -v) unlimited
>>
>> So the stack may grow up to the virtual address range which is pretty 
>> huge on 64-bit platforms. No physical memory is enough to allocate 
>> stack this big, so the system starts swapping nonstop. Maybe OOM linux 
>> killer will kill this process after some time, maybe not.
>>
>>> Is there a way the test framework could set this?  Does DRLVM support 
>>> -Xss yet?
>>
>> -Xss is the lower stack limit, it doesn't specify the maximum stack 
>> size, doesn't it?
> 
> What does "lower stack limit" mean? :)  I think that it's the size of 
> the stack, max.

I thought it is a starting stack size, like -Xms for heap size. Now that 
I searched the web it appears that it is the maximum indeed.

> I think all you need to do then is set the stack size :
> 
>    ulimit -s 8192
> 
> or something.  We should probably do this before each run on linux so 
> that things are well defined and reproducible.

I think 64-bit SuSE9 is just the only weird distribution which doesn't 
have this limit. In 10th version they fixed this. So ulimit -s is not 
necessary in most cases.

I'd still like to have a recursion limit in StackTest but Rana has 
convinced me that no SOE shouldn't mean that test has failed. I'll patch 
it now.

-- 
Gregory