From: "Edgar Gonçalves" <edgar.goncalves@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: David Reitter <david.reitter@gmail.com>, 7920@debbugs.gnu.org
Subject: bug#7920: 24.0.50; Crash in balance_an_interval + 26
Date: Thu, 27 Jan 2011 16:32:55 +0000 [thread overview]
Message-ID: <B3AEB224-FDF5-4505-BC93-962D239B6265@gmail.com> (raw)
In-Reply-To: <jwv62tbm3lg.fsf-monnier+emacs@gnu.org>
On Jan 27, 2011, at 3:31 AM, Stefan Monnier wrote:
> Looking at the backtrace, the crash is probably not really in
> balance_an_interval; instead what happened is that Emacs got stuck in an
> infinite recursion and the OS killed the process when it reached the
> maximum allowed stack depth, which happened to be when Emacs was in
> balance_an_interval.
>
> I couldn't find any user-provided info in the bug-report, is that right?
I'm sorry I didn't file a description with this bug report, i forgot and sent the email... But in short, this has been happening when I'm using slime to connect to an emacs-launched clojure shell process. In particular, it happens when clojure hangs, and I don't know how to collect more details at this point - next time it happens I'll provide you with more.
> If I understand the backtrace right, it seems that the infinite
> recursion went through `funcall', so it was an infinite recursion within
> Elisp, and those are supposed to be caught before reaching the
> maximum allowed stack depth thanks to limits like max-specpdl-size.
>
> So, maybe the bug is that max-specpdl-size is larger than the OS allows,
> in which case we should try and figure out why that is: is it because
> someone set it explicitly higher (too high), or because the OS's maximum
> stack depth is lower than we thought?
Hmm, this may be indeed the case that my max-specdpl-size is too high. This is in part due to me not knowing what "too high" means for my machine - how can I calculate the optimal value? I remember having set it up to 100000 to be able to use a cedet/javasee function (guided by some solution posted on a blog whose name, i'm afraid, i can't recall). Why should Emacs set this value to anything lower than the maximum supported value, does it affect the system performance/resources?
It has been working thus far, though, except with this occasional infinite recursion using slime. I've now set that variable's value to the default (removing my customization), and I'll see if I run into more problems.
Thanks,
--
Edgar Gonçalves
next prev parent reply other threads:[~2011-01-27 16:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <B4C0695C-5EDB-4196-A9A9-7ACF2A695634@gmail.com>
2011-01-26 15:14 ` bug#7920: 24.0.50; Crash in balance_an_interval + 26 David Reitter
2011-01-27 3:31 ` Stefan Monnier
2011-01-27 16:32 ` Edgar Gonçalves [this message]
2011-01-27 17:37 ` Stefan Monnier
2012-03-27 0:29 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B3AEB224-FDF5-4505-BC93-962D239B6265@gmail.com \
--to=edgar.goncalves@gmail.com \
--cc=7920@debbugs.gnu.org \
--cc=david.reitter@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).