From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" Date: Mon, 24 Oct 2016 10:05:58 +0300 Message-ID: <83eg365iqx.fsf@gnu.org> References: <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87h98hujcx.fsf@users.sourceforge.net> <831szkahyz.fsf@gnu.org> <87eg3jvfj6.fsf@users.sourceforge.net> <8360ov8lbu.fsf@gnu.org> <877f95uj66.fsf@users.sourceforge.net> <83zim0vn1t.fsf@gnu.org> <874m48v7wj.fsf@users.sourceforge.net> <83insov1zr.fsf@gnu.org> <87zilztzd5.fsf@users.sourceforge.net> <83oa2ftnvp.fsf@gnu.org> <87wph2ts1a.fsf@users.sourceforge.net> <83oa2erx0k.fsf@gnu.org> <87lgxht8hp.fsf@users.sourceforge.net> <871sz8kq2v.fsf@gmail.com> <87shroroh8.fsf@users.sourceforge.net> <838ttfpnxt.fsf@gnu.org> <83vawjo21l.fsf@gnu.org> <83bmybnopx.fsf@gnu.org> <8360ojnk0n.fsf@gnu.org> <83twc3m198.fsf@gnu.org> <83pomrlz27.fsf@gnu.org> <83lgxenao0.fsf@gnu.org> <83insin9n8.fsf@gnu.org> <83h982n7k4.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477292906 18250 195.159.176.226 (24 Oct 2016 07:08:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 07:08:26 +0000 (UTC) Cc: sam.halliday@gmail.com, 24358@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 24 09:08:22 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byZMc-0002DM-4e for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Oct 2016 09:08:06 +0200 Original-Received: from localhost ([::1]:44976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byZMe-0002GQ-Fi for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Oct 2016 03:08:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byZLe-0001fo-43 for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 03:07:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byZLZ-0005hC-VX for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 03:07:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36130) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byZLZ-0005h8-Rv for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 03:07:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1byZLZ-00043J-Jh for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 03:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Oct 2016 07:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24358 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch fixed Original-Received: via spool by 24358-submit@debbugs.gnu.org id=B24358.147729277215517 (code B ref 24358); Mon, 24 Oct 2016 07:07:01 +0000 Original-Received: (at 24358) by debbugs.gnu.org; 24 Oct 2016 07:06:12 +0000 Original-Received: from localhost ([127.0.0.1]:51525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byZKl-00042D-W3 for submit@debbugs.gnu.org; Mon, 24 Oct 2016 03:06:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byZKk-00041y-6a for 24358@debbugs.gnu.org; Mon, 24 Oct 2016 03:06:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byZKb-0005XW-M8 for 24358@debbugs.gnu.org; Mon, 24 Oct 2016 03:06:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byZKb-0005XQ-Im; Mon, 24 Oct 2016 03:06:01 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1360 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byZKa-00063A-Pn; Mon, 24 Oct 2016 03:06:01 -0400 In-reply-to: (message from Noam Postavsky on Sun, 23 Oct 2016 19:18:32 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:124943 Archived-At: > From: Noam Postavsky > Date: Sun, 23 Oct 2016 19:18:32 -0400 > Cc: Sam Halliday , 24358@debbugs.gnu.org > > Eli Zaretskii wrote: > > Noam, do you configure Emacs with --enable-check-lisp-object-type? > > If not, please do, because that's what Sam does; perhaps that is the > > reason why he gets the problem and you don't. > > > > One other difference is that Sam is running a bootstrap, so his > > bootstrap-emacs used to build ja-dic has the necessary Lisp files > > loaded as *.el files, not *.elc. Therefore another thing to try > > (perhaps even before reconfiguring) is a full bootstrap, preferably in > > a separate clean directory, maybe you will see this problem then. > > I will try both of these tomorrow. Thanks. Here are some other things to try, if you (or someone else) have time: . build regex.c with REGEX_MALLOC defined, and see whether your recent additions to cater to relocation are needed with that configuration . build with gmalloc.c, but without ralloc.c (I will try to come up with a recipe or a patch for that later today, if no one beats me to it) . surround the calls to regex.c functions in search.c and elsewhere with the calls to r_alloc_inhibit_buffer_relocation, again without your recent additions to regex.c (the problem with this is that it must be tested in long, real-life sessions, because in the past using that workaround caused very rare crashes in ralloc.c itself, which were supposed to be fixed, but were never tested thoroughly enough, AFAIK) > > Noam, there's something I don't understand here: why is regex.c using > > malloc for allocating the failure stack? AFAICS, REGEX_MALLOC is not > > defined, so the only way I can explain this to myself is that we use > > SAFE_ALLOCA, and that falls back to malloc because the failure stack > > needs more than 16KB of memory. Is that correct? > > Yes, this is correct, see also > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#47 > > > > > If so, then one other way of solving the original problem that doesn't > > open the gates of the ralloc.c hell is to allow a larger amount of > > stack allocations in regex.c before we fall back to malloc. Since the > > maximum size of the failure stack is limited by something like 800KB, > > and the C stack limit is set in main.c to allow the failure stack be > > allocated off the stack, why don't we make use of this fact? > > It sounds reasonable in principle. This would mean changing MAX_ALLOCA? Actually, it probably means using a different definition for SAFE_ALLOCA in regex.c, or a separate macro. I don't see the need to increase stack usage elsewhere in Emacs. Thanks.