From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Sam Halliday 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 21:13:33 +0100 Message-ID: References: <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> <83k2cynabi.fsf@gnu.org> <87eg35swni.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1477340551 31765 195.159.176.226 (24 Oct 2016 20:22:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 20:22:31 +0000 (UTC) Cc: 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 22:22:26 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 1byll1-0005kD-9O for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Oct 2016 22:22:07 +0200 Original-Received: from localhost ([::1]:49774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byll3-0007gm-Gr for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Oct 2016 16:22:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byldG-0000Dr-Mw for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 16:14:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byldC-0002vM-C3 for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 16:14:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39546) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byldC-0002v2-85 for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 16:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1byldB-0008LF-W1 for bug-gnu-emacs@gnu.org; Mon, 24 Oct 2016 16:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sam Halliday Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Oct 2016 20:14: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.147734002332025 (code B ref 24358); Mon, 24 Oct 2016 20:14:01 +0000 Original-Received: (at 24358) by debbugs.gnu.org; 24 Oct 2016 20:13:43 +0000 Original-Received: from localhost ([127.0.0.1]:54945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bylct-0008KT-28 for submit@debbugs.gnu.org; Mon, 24 Oct 2016 16:13:43 -0400 Original-Received: from mail-yw0-f182.google.com ([209.85.161.182]:36475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bylcr-0008KE-5a for 24358@debbugs.gnu.org; Mon, 24 Oct 2016 16:13:41 -0400 Original-Received: by mail-yw0-f182.google.com with SMTP id u124so13987573ywg.3 for <24358@debbugs.gnu.org>; Mon, 24 Oct 2016 13:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pT5r7mG5XvSJWCEaOHSm/738MHFsB4+fiLBzDRy617k=; b=JF7/9rpBhWkaSsvVtKZphgkcwqffCXKbcX8MwVEdUBECGL5Z5MiZfHIlU0qcXkbBXw d6niIqpuM1KqhlxVXZxij3QQxnz1VU4LYWCS6RRQxWoJe1CzE+v+LKSDgiS6g4b5g0iG yqV6aD2VnDPnqLHpTvKj41TkhEcpj2skq52VXE9HZZ+M0RKTH+kW22MnltXAa6xRER9m WYScAu2anbQfYdnsWOwSke7Y3YRR2CLlpgAeqOv22+DFGtIN/kxkzQAzxtciIsuWi2Ru VCmqPhgS9fzY0amhtnKkzr018CBmtke7cwx44B0DdEjwxjdIqtzJrGl9LWy3v+WIq2dq kIEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pT5r7mG5XvSJWCEaOHSm/738MHFsB4+fiLBzDRy617k=; b=JwYt5g5STJVCCJi1cj5JveLgthuDNtDBrhtHniiII+hkNVRqyxSSViimwUNEvUs2xC FpVt6ZotOAXQW1+BAKKvcB+JtrDioWPAXKcY9bbrS6iP88WFLjMdagCiphu52nWzfsgz quoO8knMiZVLhV3zWGo8Ek7GT0I5prCxgMD5FpbXA1G5MVR7M/C6ACvulA3H0aMVd77x urCobc6fBjpE7Axv5ee0CkPPQN5gVorKyX2yXI6XZbl0vc4uSIjd+0HVFLO8kvYsqoVQ lNQC+FAOfuMUwQKLaGXmVS5l/sHua9g9WQDcBhEzcmQrXVCY5UM1g6Is/8WUBlTT1UdN ZFCg== X-Gm-Message-State: ABUngvcPL+s/8FXxKOSrXlW4e9TU8GnI8QrnKkmBlfQC5uuF+yzzz8ey0U8fRNIsiYCm1coks7PkiBnqrbOQiQ== X-Received: by 10.107.3.78 with SMTP id 75mr13475796iod.75.1477340015190; Mon, 24 Oct 2016 13:13:35 -0700 (PDT) Original-Received: by 10.50.223.166 with HTTP; Mon, 24 Oct 2016 13:13:33 -0700 (PDT) In-Reply-To: <87eg35swni.fsf@users.sourceforge.net> 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:124973 Archived-At: I built 96ac0c3 and got a problem with the same part of the build, but this time at 10%. Apologies, I don't have the free time to do another debug run on it tonight. I tried with REL_ALLOC=no and that builds fine! Thank you for the workaround. I will still try to help with debug info. Re: docker, it is libre software and you should be able to install it using whatever package manager you have. It allows you to run containerised GNU distributions using your current linux kernel. Pre-built images are made available through the "hocker hub", e.g. https://hub.docker.com/r/base/archlinux/ If you have docker installed you would type something like this (don't forget to add your user to the docker group) docker run -it base/archlinux and (after downloading the "layers"), it will drop you into a shell running that OS. ArchLinux uses "pacman" as the package manager and you might need to run something like "pacman -S devel-base emacs" to get everything you need. Once you exit this shell, all your changes are lost, so you might want to investigate mounting a local directory into the container, e.g. so you don't need to download emacs git tree every time. I'm no expert, I've only used it a few times before but it is invaluable when it works. On 24 October 2016 at 14:29, wrote: > I was able to reproduce the failure in ja-dic-cnv after removing > --with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no > --with-jpeg=no from my configure args (I guess using GTK changes the > allocation patterns), and doing 'make extraclean'. > > The error went away after I updated to the latest emacs-25 commit: > ee04aedc72 "Fix handling of buffer relocation in regex.c functions". > The error occurs in the commit just before it 71ca4f6a "Avoid relocating > buffers while libxml2 reads its text", so I think Eli's fix for the base > pointer in search_buffer does solve the problem. > > Sam, can you confirm if this fixes it for you? > > Eli Zaretskii writes: > >>> From: Noam Postavsky >>> Date: Sun, 23 Oct 2016 14:14:59 -0400 >>> Cc: Sam Halliday , 24358@debbugs.gnu.org >>> >>> On Sun, Oct 23, 2016 at 2:06 PM, Eli Zaretskii wrote: >>> > Noam, I think we need these two changes, because otherwise looping >>> > more than once in search_buffer will fail to update the pointers >>> > passed to re_search_2, if buffer text was relocated inside >>> > re_search_2. >>> > >>> > Do you agree? >>> >>> Ack, yes! Missing the update to base was a total thinko on my part. >> >> Pushed. >> >> There might be a more serious problem with this, unfortunately: the >> search registers are computed in regex.c using pointers into the C >> strings that are being searched. The general paradigm is as in this >> fragment: >> >> regstart[*p] = d; >> [...] >> regs->start[reg] = POINTER_TO_OFFSET (regstart[reg]); >> >> POINTER_TO_OFFSET assumes that the pointer in regstart[reg] is >> consistent with the current base address of the string into which it >> points. Did you study this aspect of regex.c when you decided which >> values need to be affected by relocation? > > I did not look at that before, but looking now, I don't see why it would > be a problem. I put the base address updating code around the only > place where malloc may be called, so string1 and string2 (which > POINTER_TO_OFFSET uses) should always be consistent with the base > address (unless there is some other malloc call that I missed?).