site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Alpine 1.00 (OSX 882 2007-12-20) That is because of me. Consider fixing your code. -k. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Sun, 2 Mar 2008, Terry Lambert wrote: On Mar 1, 2008, at 1:57 PM, Ken Mankoff <mankoff@gmail.com> wrote: On Sat, 1 Mar 2008, Michael Smith wrote: On Mar 1, 2008, at 11:20 AM, Ken Mankoff wrote: I'm running out of stack space with an application I need to run. I have "ulimit -s 64000" in my .bash_profile. The highest value I can set is 65532. At 65533 it reports, "/usr/bin/ulimit: line 4: ulimit: stack size: cannot modify limit: Invalid argument" I read somewhere that the kernel limits it to 64MB. I figure this is the right place to get a definitive answer and further information. Is it 64 really the limit? How would I allow multiple processes to each have 128 or 256MB each? I'm comfortable recompiling a kernel if need be. Thanks for any advice, 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. 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 OK thank you all for the feedback. We haven't actually run into a 64MB limit but are concerned we might. It sounds unlikely based on the Oracle comments, but I think I have a pretty good idea of how to approach it should we require more. This email sent to site_archiver@lists.apple.com