bug#27571: C stack overflow from `prin1' on deeply nested lisp object.

[Keith David Bershatsky]

After several Google searches, it appears that there is a 65532 (65 MB) hard 
limit on the stack size for OSX 10.6.8 and at least a few subsequent iterations 
of the OS.

$ ulimit -a

* * *
stack size (kbytes, -s) 8192
* * *

$ ulimit -s 65533
-bash: ulimit: stack size: cannot modify limit: Operation not permitted

$ ulimit -s 65532

$ [Back to a command prompt without any error message; i.e., the operation 
succeeded.]

We now know that `ulimit -S -s unlimited` gives me only 65532.

I still have a note on my "to-do list" to perform hard resets of Emacs 25 
branch going back in time to each of the thirteen (13) commits mentioned in 
Message #41 of this thread to pinpoint which one caused me to launch this 
bug#27571 pursuant to the merge commit on November 19, 2016 
(c61ee94959ba96b2a327df0684593f7e569e30be).  Things seemed to be working well 
prior to that commit, and reversing that commit as to emacs.c appears to make 
things work well again on my end.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27571#41

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [01-28-2018 16:13:40] <28 Jan 2018 19:13:40 -0500>
FROM:  Noam Postavsky <npostavs@users.sourceforge.net>
> 
> Keith David Bershatsky <esq@lawlist.com> writes:
> 
> >> > Second, I _did_ manually set the terminal with `ulimit -S -s
> >> > unlimited`.  The STDERR message when I open Emacs is:
> >> >
> >> >   getrlimit: 0
> >> >
> >> >   rlim.rlim_cur: 67104768
> 
> > Starting a fresh terminal session, with no special settings:
> >
> > $ ulimit -H -s
> >
> > 65532
> 
> Ah, 65532 * 1024 = 67104768, so there we are.  You just need to figure
> out if and how that limit can be lifted.