[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27571: C stack overflow from `prin1' on deeply nested lisp object.
From: |
Noam Postavsky |
Subject: |
bug#27571: C stack overflow from `prin1' on deeply nested lisp object. |
Date: |
Sun, 28 Jan 2018 16:45:23 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) |
Keith David Bershatsky <esq@lawlist.com> writes:
> From a layman's perspective, it appears to me that Emacs disregards
> `ulimit -S -s unlimited` on OSX 10.6.8 when typed into the terminal
> before launching Emacs. To the extent that Emacs can be persuaded to
> obey the "unlimited" case explicitly, that sounds like a viable
> solution. I must admit, however, that I am unfamiliar with how this
> all works.
Can you check with gdb what the values of rlim are in this case? Around
here, after the getrlimit call:
if (getrlimit (RLIMIT_STACK, &rlim) == 0
&& 0 <= rlim.rlim_cur && rlim.rlim_cur <= LONG_MAX)
On GNU/Linux, rlim.rlim_cur is 0xffffffffffffffff (or -1 if interpreted
as a signed integer), so that if condition evaluates to false.