Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Pavel Afremov wrote:
On 11/13/06, Gregory Shimansky <[EMAIL PROTECTED]> 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 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.
geir