bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]