Thanks! True, the hard limit in these xterms is also 512. It does sound like the limit for threads, not for processes.
Trouble is that this is a new installation of both MacOS and XQuartz. On my past system, my xterms had the usual 65532 hard limits. Did anyone try this in MacOS 10.12.5 ? Could it be that something in the windows opened by the OS on behalf of X11 changed in this OS release? [I am also not sure which configuration script(s) for X11 might even be relevant … I think I never touched any of these, since the early 2000’s on Linux … hm.] Best Volker > On Jul 11, 2017, at 7:18 PM, Mike Thornburg <[email protected]> wrote: > > On Tue, 11 Jul 2017, Tom Lane wrote: > >> "David Ledger" <[email protected]> writes: >>> On 11 Jul 2017, at 14:18, Volker Blum wrote: >>>> When I open a new xterm, and say ulimit -a, I get: >>>> stack size (kbytes, -s) 512 > > I agree with the others. Based on tests on my system 512 kbytes is unusually > low for a stack size limit and does not seem to be the default. I'm running > MacOS 10.10.5 and both my xterms and Terminal.app default to a stack size > limit of 8192K. > > To be more specific, they default to a soft limit of 8192K. The hard limit > is 65532K: > > sh-3.2$ ulimit -Hs > 65532 > > The way these limits work is that a process is allowed to increase or > decrease the soft limit at will as long as it does not set the soft limit to > exceed the hard limit. For anyone but the superuser the hard limit may only > be decreased, and once decreased may never be increased again by that process > or by any of its children. > > Note these words in "man sh" where it describes the operation of the built-in > ulimit command: "If neither -H nor -S is specified, both the soft and hard > limits are set." This is likely why you are only able to change the stack > limit once after opening Terminal: you are not specifying -S as part of the > ulimit command so both soft and hard limits are being changed. > > I agree with Tom that what has likely happened to you is that some > initialization script that you run in the process of getting a shell running > in your xterm (perhaps some script involved in starting up your X windows > environment) has a ulimit command in it to set the stack size limit to 512k. > Because this command was not given the -S parameter, both the soft and the > hard limits were set to 512k and the shell process that inherits this limit > is not allowed to increase it. > > You can confirm that the hard limit has also been changed to 512k by giving > the "ulimit -a -H" command on your system. > > Mike > >> >>> I’m running a Mac mini at 10.6.8, Darwin Kernel Version 10.8.0, and a >>> MBP at 10.11.6, Darwin Kernel Version 15.6.0. Without me doing anything >>> other than exec’ing a ksh both give me a stack size of 8192K. A >>> ‘Terminal’ window gives the same. >> >> Yes, I get the same results as David; also >> >> $ ulimit -a -H >> 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) unlimited >> pipe size (512 bytes, -p) 1 >> stack size (kbytes, -s) 65532 >> cpu time (seconds, -t) unlimited >> max user processes (-u) 1064 >> virtual memory (kbytes, -v) unlimited >> >> which shows (and experimentation confirms) that I can set the stack size >> limit to anything under 64M. >> >> There's some useful info here >> >> https://developer.apple.com/library/content/qa/qa1419/_index.html >> >> which suggests that a 512K stack is what macOS defaults to for a >> pthread. I doubt your shell per se would have become threaded, >> but maybe it was launched from a thread of a multithreaded program. >> I wonder if you have anything unusual in your ~/.bashrc, X startup >> scripts, etc. >> >> regards, tom lane _______________________________________________ Do not post admin requests to the list. They will be ignored. X11-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com This email sent to [email protected]
