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

[Keith David Bershatsky <esq@lawlist.com>]

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.