[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: |
Tue, 09 Jan 2018 08:43:08 -0800 |
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [01-09-2018 04:58:34] <09 Jan 2018 07:58:34 -0500>
FROM: Noam Postavsky <npostavs@users.sourceforge.net>
>
> Keith David Bershatsky <esq@lawlist.com> writes:
>
> > I have determined that bug #27571 was introduced on November 19, 2016
> > with commit c61ee94959ba96b2a327df0684593f7e569e30be. The following
> > patch to the Emacs 26 branch as of today (01/08/2018) reverses the
> > commit and enables the test below to be completed successfully.
> >
> > [FYI: I am on OSX 10.6.8 and am manually increasing the stack limit
> > with `ulimit -S -s unlimited` so that I can have rather large custom
> > undo-tree histories.]
>
> By "broken" you mean that it prevents the `ulimit -S -s unlimited` trick
> from working? Perhaps it's just a matter of detecting this "unlimited"
> case explicitly.
- bug#27571: C stack overflow from `prin1' on deeply nested lisp object.,
Keith David Bershatsky <=