Re: ulimit stack information
Re: ulimit stack information
- Subject: Re: ulimit stack information
- From: Shantonu Sen <email@hidden>
- Date: Sat, 1 Mar 2008 22:15:25 -0800
Do you have access to the source of this program? You can relink it
with an arbitrarily large stack size. For example:
# printf "%x\n" $((512*1024*1024))
20000000
# cc test.c -Wl,-stack_size,20000000
ld warning: custom stack placement overlaps and will disable shared
region
#
That seems to work for me. If you don't have access to the source, you
can probably write a program to rewrite the Mach-O load commands to
add a __UNIXSTACK segment and modify the LC_UNIXTHREAD load command
Shantonu
Sent from my MacBook
On Mar 1, 2008, at 9:53 PM, Michael Smith wrote:
On Mar 1, 2008, at 1:57 PM, Ken Mankoff wrote:
First suggestion; fix the app so that it uses less than 64MiB of
stack. Hard, but realistically that much stack usage points to a
design/algorithmic flaw (Resource consumption that scales 1:1 with
some aspect of your dataset directly constrains the dataset that
you can manage vs. the availability of the resource in question.)
I can't do this. This is 100 000 + lines that is a global climate
model.
You should nevertheless propagate the issue back to the
developer(s). It's worst with "scientific" code (I speak from
personal experience) but the long-term consequences aren't so great
either.
Second suggestion: you have hit the hard limit; you need to be
root to increase it. You can either run the shell as root, or
write a setuid root wrapper for your application that uses
setrlimit(2) to bump both the hard and soft limits up before
starting the application.
I tried the 'ulimit' command w/ sudo. Won't go above 65532. Even
with "-H".
It's not clear to me how you invoked ulimit with sudo, given that it
is a shell builtin, but you're right; the kernel constrains the
maximum stack to 64MiB via the definition of MAXXSIZ in vmparam.h (I
should have tested before replying to you, sorry about that).
If you're comfortable rebuilding the Darwin kernel for your system,
you might try bumping this up, but it's not clear to me that you
won't run into other problems with the process memory map
(specifically, I'm not clear on whether there's room for it to be
bigger).
Another approach you might try is to wrap the top level of your
simulation in a pthread and allocate a larger stack for that thread;
I'm not certain that this would work either but it wouldn't be
terribly difficult to try.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden