[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: |
Keith David Bershatsky |
Subject: |
bug#27571: C stack overflow from `prin1' on deeply nested lisp object. |
Date: |
Sun, 28 Jan 2018 15:23:47 -0800 |
I inserted some sprintf messages in emacs.c as follows:
fprintf (stderr, "getrlimit: %d\n", getrlimit (RLIMIT_STACK, &rlim));
if (getrlimit (RLIMIT_STACK, &rlim) == 0
&& 0 <= rlim.rlim_cur && rlim.rlim_cur <= LONG_MAX)
{
fprintf (stderr, "rlim.rlim_cur: %d\n", rlim.rlim_cur);
First, I did _not_ manually set the terminal with `ulimit -S -s unlimited` --
i.e., just plain old terminal, with nothing special. The STDERR message when I
open Emacs is:
getrlimit: 0
rlim.rlim_cur: 8388608
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
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [01-28-2018 13:45:23] <28 Jan 2018 16:45:23 -0500>
FROM: Noam Postavsky <npostavs@users.sourceforge.net>
>
> Keith David Bershatsky <esq@lawlist.com> writes:
>
> * * *
>
> 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.