From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 May 2012 16:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 11519@debbugs.gnu.org X-Debbugs-Original-To: Bug-Gnu-Emacs Received: via spool by submit@debbugs.gnu.org id=B.133744389226479 (code B ref -1); Sat, 19 May 2012 16:12:02 +0000 Received: (at submit) by debbugs.gnu.org; 19 May 2012 16:11:32 +0000 Received: from localhost ([127.0.0.1]:34582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVmFf-0006t2-JM for submit@debbugs.gnu.org; Sat, 19 May 2012 12:11:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42941) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVmFd-0006sn-1b for submit@debbugs.gnu.org; Sat, 19 May 2012 12:11:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVmF5-0007gK-7u for submit@debbugs.gnu.org; Sat, 19 May 2012 12:10:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:32826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVmF5-0007gG-26 for submit@debbugs.gnu.org; Sat, 19 May 2012 12:10:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVmF3-0003mj-BA for bug-gnu-emacs@gnu.org; Sat, 19 May 2012 12:10:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVmF1-0007fn-GN for bug-gnu-emacs@gnu.org; Sat, 19 May 2012 12:10:52 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:44991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVmF1-0007eQ-7p for bug-gnu-emacs@gnu.org; Sat, 19 May 2012 12:10:51 -0400 Received: by pbbrp2 with SMTP id rp2so5562588pbb.0 for ; Sat, 19 May 2012 09:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=Xj4mSYDdeAkaj3n9jMpWi7Jvx4tGjDYwdrAxNkm53sE=; b=uElw2pLxyt88vO2AogVUnGtjOu6UOtXZX4UR+lQSGCo/J6vt8j9T9DSkjAbqaSm0/j lBhG4oiS7Kbh72z5TSMVnLuQBVQthwBtBxhORiJNbwrgX/7fNBRVyhAPIgHV6Mnv/Cre uwFZzLHSkvJmcc1ylPJtJhkI2jPqU5GkZKmNGvNA2cxL7hqSOI4XuWdWweOXajS5L2dM ojw2HIiWN4AMrP46IVhhgO5kPkZ12PmHXNCdK66AETbQwB86LsXIK8UceK5W/atQfBSa xUvsEEklXdBu7Y9k9KHnTVg32mbYq0BbKXc6wTrsoMO2pinpulBz9XX3nvauy/g9ZhOU 1YyA== Received: by 10.68.190.131 with SMTP id gq3mr51445494pbc.17.1337443848271; Sat, 19 May 2012 09:10:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.19.8 with HTTP; Sat, 19 May 2012 09:10:07 -0700 (PDT) From: Juanma Barranquero Date: Sat, 19 May 2012 18:10:07 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Package: emacs Version: 24.1.50 With current trunk (revno:108308) bootstrapping on Windows throws an error while building custom-deps: make -w cus-load.el-CMD make[2]: Entering directory `C:/emacs/debug/lisp' echo ;;; cus-load.el --- automatically extracted custom dependencies> cus-load.el-CMD echo ;;>> cus-load.el-CMD echo ;;; Code:>> cus-load.el-CMD echo.=0C>> cus-load.el-CMD echo ;; Local Variables:>> cus-load.el-CMD echo ;; version-control: never>> cus-load.el-CMD echo ;; no-byte-compile: t>> cus-load.el-CMD echo ;; no-update-autoloads: t>> cus-load.el-CMD echo ;; End:>> cus-load.el-CMD make[2]: Leaving directory `C:/emacs/debug/lisp' mv cus-load.el-CMD C:/emacs/debug/lisp/cus-load.el Directories: calc calendar emacs-lisp emulation erc eshell gnus international language mail mh-e net nxml org play progmodes textmodes url vc cedet ce "../src/oo/i386/emacs.exe" -batch --no-site-file --no-site-lisp -l cus-dep --eval "(setq find-file-hook nil)" \ -f custom-make-dependencies C:/Devel/emacs/repo/debug/lisp calc calendar emacs-lisp emulation erc eshell gnus international language Directory C:/emacs/debug/lisp Directory calc Directory calendar Directory emacs-lisp Directory emulation Directory erc Directory eshell Directory gnus Directory international Directory language Wrong type argument: characterp, 4195283 make[1]: [custom-deps] Error -1 (ignored) rm "../src/oo/i386/emacs.exe" After bootstraping, cd lisp make custom-deps works as expected. The error appeared somewhere in the past ten days or so (I have a bootstrap log from 2012-05-08 which does not show the problem). =C2=A0 =C2=A0 Juanma From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 May 2012 16:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juanma Barranquero Cc: 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133744487527884 (code B ref 11519); Sat, 19 May 2012 16:28:01 +0000 Received: (at 11519) by debbugs.gnu.org; 19 May 2012 16:27:55 +0000 Received: from localhost ([127.0.0.1]:34591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVmVX-0007Fh-3y for submit@debbugs.gnu.org; Sat, 19 May 2012 12:27:55 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:34299) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVmVU-0007FU-Tg for 11519@debbugs.gnu.org; Sat, 19 May 2012 12:27:54 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M4A000002RRUV00@a-mtaout23.012.net.il> for 11519@debbugs.gnu.org; Sat, 19 May 2012 19:27:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4A000LN31HPV40@a-mtaout23.012.net.il>; Sat, 19 May 2012 19:27:17 +0300 (IDT) Date: Sat, 19 May 2012 19:27:19 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83d360yw48.fsf@gnu.org> References: X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Juanma Barranquero > Date: Sat, 19 May 2012 18:10:07 +0200 > > Directory language > Wrong type argument: characterp, 4195283 > make[1]: [custom-deps] Error -1 (ignored) Can you try finding out which file in lisp/language causes that, and on which line? From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 May 2012 21:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133746368423108 (code B ref 11519); Sat, 19 May 2012 21:42:01 +0000 Received: (at 11519) by debbugs.gnu.org; 19 May 2012 21:41:24 +0000 Received: from localhost ([127.0.0.1]:34752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVrOt-00060e-JS for submit@debbugs.gnu.org; Sat, 19 May 2012 17:41:23 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:53253) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVrOr-00060P-C5 for 11519@debbugs.gnu.org; Sat, 19 May 2012 17:41:21 -0400 Received: by pbcwy7 with SMTP id wy7so4896050pbc.3 for <11519@debbugs.gnu.org>; Sat, 19 May 2012 14:40:47 -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:content-type:content-transfer-encoding; bh=k1xbpHXwRVAa1ybH9I+QbeHBu8Dj67MGNnUXDBBNV3o=; b=pcaoajyRSmkyL3gN9lSseDJXMbNDr/bpzC9idAezaPY9PUxBTrWuzOsmWyAz5iX/FK C1Cpt/CEvuDcRnKEmy/srRhKux6PM3tFdAALGFader99kTi2QKX3FA8ppUFG5+d5QJGH qx7RgbB2cocePN112TD/RfXioq+jpFjuGP9sPEOHfi35NXo4buSMOan9vdPOQeqN9KgY DyY978dD1us6CE6a8dz3jAVaNTiooWdPB5936vwAsVkVDaCVr4qFHHdL8grII8fav8Vg GQZWy606WJdIPek+qbNkvd1M6GT98utW2k1cz3ECow/18eaivoxtG8cxGZ2DFyjOcTHr yFIQ== Received: by 10.68.197.99 with SMTP id it3mr21313304pbc.148.1337463646873; Sat, 19 May 2012 14:40:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.19.8 with HTTP; Sat, 19 May 2012 14:40:06 -0700 (PDT) In-Reply-To: <83d360yw48.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> From: Juanma Barranquero Date: Sat, 19 May 2012 23:40:06 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > Can you try finding out which file in lisp/language causes that, and > on which line? Yes, but it is slow; it only happens on bootstraps. =C2=A0 =C2=A0 Juanma From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 May 2012 17:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juanma Barranquero Cc: 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.1337534897828 (code B ref 11519); Sun, 20 May 2012 17:29:01 +0000 Received: (at 11519) by debbugs.gnu.org; 20 May 2012 17:28:17 +0000 Received: from localhost ([127.0.0.1]:35594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SW9vB-0000Cf-VU for submit@debbugs.gnu.org; Sun, 20 May 2012 13:28:16 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:39073) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SW9ur-0000C8-FJ for 11519@debbugs.gnu.org; Sun, 20 May 2012 13:27:56 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4C008000F0JU00@a-mtaout20.012.net.il> for 11519@debbugs.gnu.org; Sun, 20 May 2012 20:26:57 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4C007590GXIOH0@a-mtaout20.012.net.il>; Sun, 20 May 2012 20:26:57 +0300 (IDT) Date: Sun, 20 May 2012 20:27:02 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834nrazrtl.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Juanma Barranquero > Date: Sat, 19 May 2012 23:40:06 +0200 > Cc: 11519@debbugs.gnu.org > > > Can you try finding out which file in lisp/language causes that, and > > on which line? > > Yes, but it is slow; it only happens on bootstraps. If you started looking, I think you can stop. It's a %$#@! heisenbug. If I add a single (message %s file) to custom-make-dependencies, it displays ethio-util.el as the last file name before the error. But adding another message makes the problem disappear, and the bootstrap runs flawlessly to completion. Likewise, running just "make custom-deps" with the emacs.exe built by the first stage of the bootstrap doesn't produce any errors. I will try a few more tricks; ideas for how to debug this, or where to look, are welcome. If you say that this started happening only lately, perhaps bisecting might give some insights. Thanks. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 May 2012 19:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133754051912175 (code B ref 11519); Sun, 20 May 2012 19:02:02 +0000 Received: (at 11519) by debbugs.gnu.org; 20 May 2012 19:01:59 +0000 Received: from localhost ([127.0.0.1]:35637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWBOB-0003AJ-Fv for submit@debbugs.gnu.org; Sun, 20 May 2012 15:01:59 -0400 Received: from mail-pz0-f44.google.com ([209.85.210.44]:57315) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWBO9-0003A7-CU for 11519@debbugs.gnu.org; Sun, 20 May 2012 15:01:58 -0400 Received: by dacx6 with SMTP id x6so5358734dac.3 for <11519@debbugs.gnu.org>; Sun, 20 May 2012 12:01:18 -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:content-type:content-transfer-encoding; bh=bAHhNteqLB2zmDaVi47EsFD7/+KjJyrkRnP3Eg7pF0A=; b=Nv1INjRZTqH+I+Zam7nwfXdFOqodRQhfVV9SwRh0l8RQZmLJPYHB5e9dZPrkIN3YNC jhlW6m0JYtVas3AQRDp2N6XbBGi2BpVFx0yOVDkbsUVBGmGthIn0uSgA42mmJiLQ3+FX BavgbZ2JM6xhJ07A6dQA8QjPaXvh/svxKzQfIn5MdLk3eD3MvGbCfu7nwWPz5BP9ZJXg ZbAVkeo5JNI/om6ovSur2fsyszr2/C0EfVgykYGvwlryogVUHLGyeGzP152l3qchkUHt SAJn9TyWNiA2MdPECcaljQYDv6FR91wKXdZzTtk2+Xe8y7TSmb5BJ7GLJ/jF/0GrrvuU 4CNg== Received: by 10.68.197.99 with SMTP id it3mr29590561pbc.148.1337540477800; Sun, 20 May 2012 12:01:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.19.8 with HTTP; Sun, 20 May 2012 12:00:37 -0700 (PDT) In-Reply-To: <834nrazrtl.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> From: Juanma Barranquero Date: Sun, 20 May 2012 21:00:37 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Sun, May 20, 2012 at 7:27 PM, Eli Zaretskii wrote: > If you started looking, I think you can stop. =C2=A0It's a %$#@! > heisenbug. I didn't start, I was far from home today. > If you say that this started happening only lately, perhaps bisecting > might give some insights. The bug disappears if you revert this change: revno: 108157 committer: Glenn Morris branch nick: trunk timestamp: Mon 2012-05-07 21:50:17 -0400 message: Remove no-byte-compile setting from some lisp/language files. Same comments as per r108075, 2012-04-30, for lisp/term: Not that compiling these will bring any noticeable speed benefit, but there's really no reason not to compile them. The extra disk space and build time is negligible, and it might reveal use of obsolete functions, bugs, etc. =C2=A0 =C2=A0 Juanma From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 01:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Juanma Barranquero , 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133756498721643 (code B ref 11519); Mon, 21 May 2012 01:50:01 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 01:49:47 +0000 Received: from localhost ([127.0.0.1]:35946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWHkp-0005d2-7q for submit@debbugs.gnu.org; Sun, 20 May 2012 21:49:47 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:51741) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWHkn-0005cq-Nv for 11519@debbugs.gnu.org; Sun, 20 May 2012 21:49:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMAh0/O+K+j/2dsb2JhbAA3o0KBCIF1AQEEAVYeBQULCzQSFBgNJIgTohGLcCgQPAkDAQKDPgODcASjY4RY X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="181527690" Received: from 206-248-175-163.dsl.teksavvy.com (HELO ceviche.home) ([206.248.175.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 May 2012 21:49:05 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 9EB56660E0; Sun, 20 May 2012 21:49:02 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> Date: Sun, 20 May 2012 21:49:02 -0400 In-Reply-To: <834nrazrtl.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 May 2012 20:27:02 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > If you started looking, I think you can stop. It's a %$#@! > heisenbug. If I add a single (message %s file) to > custom-make-dependencies, it displays ethio-util.el as the last file > name before the error. But adding another message makes the problem > disappear, and the bootstrap runs flawlessly to completion. Likewise, > running just "make custom-deps" with the emacs.exe built by the first > stage of the bootstrap doesn't produce any errors. I guess the best options is to change the makefile so it sets debug-on-error (and/or starts Emacs under a debugger) in the area of interest and hope that the problem will still show up. Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 01:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juanma Barranquero Cc: Eli Zaretskii , 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133756504821744 (code B ref 11519); Mon, 21 May 2012 01:51:01 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 01:50:48 +0000 Received: from localhost ([127.0.0.1]:35950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWHlo-0005ef-Gr for submit@debbugs.gnu.org; Sun, 20 May 2012 21:50:48 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:10546) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWHln-0005eT-34 for 11519@debbugs.gnu.org; Sun, 20 May 2012 21:50:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMAh0/O+K+j/2dsb2JhbAA3o0KBCIF1AQEEAVYjBQsLDiYSFBgNJIgTohGMZAcCAQIBAoM+A4NwBKNjhFg X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="181527726" Received: from 206-248-175-163.dsl.teksavvy.com (HELO ceviche.home) ([206.248.175.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 May 2012 21:50:06 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 31035660E0; Sun, 20 May 2012 21:50:04 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> Date: Sun, 20 May 2012 21:50:04 -0400 In-Reply-To: (Juanma Barranquero's message of "Sun, 20 May 2012 21:00:37 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > The bug disappears if you revert this change: [...] > Remove no-byte-compile setting from some lisp/language files. My gut tells me this is just a trigger but not the cause of the bug :-( Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 02:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: lekktu@gmail.com, 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133756868027149 (code B ref 11519); Mon, 21 May 2012 02:52:02 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 02:51:20 +0000 Received: from localhost ([127.0.0.1]:35986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWIiO-00073q-Di for submit@debbugs.gnu.org; Sun, 20 May 2012 22:51:20 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:53599) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWIiM-00073c-08 for 11519@debbugs.gnu.org; Sun, 20 May 2012 22:51:19 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M4C00B00Q9PYM00@a-mtaout23.012.net.il> for 11519@debbugs.gnu.org; Mon, 21 May 2012 05:50:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4C00BREQKBPIA0@a-mtaout23.012.net.il>; Mon, 21 May 2012 05:50:35 +0300 (IDT) Date: Mon, 21 May 2012 05:50:41 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83396uz1q6.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Juanma Barranquero , 11519@debbugs.gnu.org > Date: Sun, 20 May 2012 21:49:02 -0400 > > > If you started looking, I think you can stop. It's a %$#@! > > heisenbug. If I add a single (message %s file) to > > custom-make-dependencies, it displays ethio-util.el as the last file > > name before the error. But adding another message makes the problem > > disappear, and the bootstrap runs flawlessly to completion. Likewise, > > running just "make custom-deps" with the emacs.exe built by the first > > stage of the bootstrap doesn't produce any errors. > > I guess the best options is to change the makefile so it sets > debug-on-error (and/or starts Emacs under a debugger) in the area of > interest and hope that the problem will still show up. I already tried the former (the problem went away). I'm guessing the latter will do the same. I will try to think about some trick, but frankly it's very frustrating, because any small change to cus-dep.el or the setup makes the problem go away. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 02:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: lekktu@gmail.com, 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133756871427199 (code B ref 11519); Mon, 21 May 2012 02:52:02 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 02:51:54 +0000 Received: from localhost ([127.0.0.1]:35989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWIiv-00074e-Ra for submit@debbugs.gnu.org; Sun, 20 May 2012 22:51:54 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:49299) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWIiu-00074P-7B for 11519@debbugs.gnu.org; Sun, 20 May 2012 22:51:52 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4C00C00QJN2800@a-mtaout22.012.net.il> for 11519@debbugs.gnu.org; Mon, 21 May 2012 05:51:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4C00B0WQLANP80@a-mtaout22.012.net.il>; Mon, 21 May 2012 05:51:10 +0300 (IDT) Date: Mon, 21 May 2012 05:51:16 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <831umez1p7.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Eli Zaretskii , 11519@debbugs.gnu.org > Date: Sun, 20 May 2012 21:50:04 -0400 > > > The bug disappears if you revert this change: > [...] > > Remove no-byte-compile setting from some lisp/language files. > > My gut tells me this is just a trigger but not the cause of the bug :-( What could be the cause, given that this commit triggers it? From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 03:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133757057829999 (code B ref 11519); Mon, 21 May 2012 03:23:02 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 03:22:58 +0000 Received: from localhost ([127.0.0.1]:36030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWJD0-0007no-Gj for submit@debbugs.gnu.org; Sun, 20 May 2012 23:22:58 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:26560) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWJCh-0007nJ-Co for 11519@debbugs.gnu.org; Sun, 20 May 2012 23:22:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMAh0/O+K+j/2dsb2JhbAA3o0KBCIF1AQEEAVYjBQsLNBIUGA0kiBOiEYxkCQECAQKDPgODcASjY4RY X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="181537302" Received: from 206-248-175-163.dsl.teksavvy.com (HELO ceviche.home) ([206.248.175.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 May 2012 23:21:57 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 4F2C2660E0; Sun, 20 May 2012 23:21:57 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <83396uz1q6.fsf@gnu.org> Date: Sun, 20 May 2012 23:21:57 -0400 In-Reply-To: <83396uz1q6.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 May 2012 05:50:41 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I already tried the former (the problem went away). I'm guessing the > latter will do the same. I will try to think about some trick, but > frankly it's very frustrating, because any small change to cus-dep.el > or the setup makes the problem go away. How 'bout changing the C code so a characterp error aborts? Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 08:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, Stefan Monnier , 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133758726625354 (code B ref 11519); Mon, 21 May 2012 08:02:02 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 08:01:06 +0000 Received: from localhost ([127.0.0.1]:36305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWNXq-0006aG-Qq for submit@debbugs.gnu.org; Mon, 21 May 2012 04:01:05 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:60196) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWNXe-0006Yw-Pm for 11519@debbugs.gnu.org; Mon, 21 May 2012 04:00:45 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3Vwspb31wLz4Kh2H; Mon, 21 May 2012 09:59:50 +0200 (CEST) Received: from igel.home (ppp-88-217-114-7.dynamic.mnet-online.de [88.217.114.7]) by mail.mnet-online.de (Postfix) with ESMTPA id 3VwspZ29q4z4KKH8; Mon, 21 May 2012 09:59:50 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id D16A0CA2A5; Mon, 21 May 2012 09:59:50 +0200 (CEST) From: Andreas Schwab References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> X-Yow: While I'm in LEVITTOWN I thought I'd like to see the NUCLEAR FAMILY!! Date: Mon, 21 May 2012 09:59:50 +0200 In-Reply-To: <831umez1p7.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 May 2012 05:51:16 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.97 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: Eli Zaretskii , 11519@debbugs.gnu.org >> Date: Sun, 20 May 2012 21:50:04 -0400 >> >> > The bug disappears if you revert this change: >> [...] >> > Remove no-byte-compile setting from some lisp/language files. >> >> My gut tells me this is just a trigger but not the cause of the bug :-( > > What could be the cause, given that this commit triggers it? Perhaps some constant sharing that the byte compiler introduces? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Schwab Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133762276019652 (code B ref 11519); Mon, 21 May 2012 17:53:02 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 17:52:40 +0000 Received: from localhost ([127.0.0.1]:37538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWWmb-00056r-GY for submit@debbugs.gnu.org; Mon, 21 May 2012 13:52:40 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:37507) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWWmX-00056X-3M for 11519@debbugs.gnu.org; Mon, 21 May 2012 13:52:35 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4D00000VZS9W00@a-mtaout22.012.net.il> for 11519@debbugs.gnu.org; Mon, 21 May 2012 20:51:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4D00MRYW98K9E0@a-mtaout22.012.net.il>; Mon, 21 May 2012 20:51:08 +0300 (IDT) Date: Mon, 21 May 2012 20:51:15 +0300 From: Eli Zaretskii In-reply-to: Message-id: <83vcjpxw18.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Andreas Schwab > Cc: Stefan Monnier , lekktu@gmail.com, = 11519@debbugs.gnu.org > Date: Mon, 21 May 2012 09:59:50 +0200 >=20 > Eli Zaretskii writes: >=20 > >> From: Stefan Monnier > >> Cc: Eli Zaretskii , 11519@debbugs.gnu.org > >> Date: Sun, 20 May 2012 21:50:04 -0400 > >>=20 > >> > The bug disappears if you revert this change: > >> [...] > >> > Remove no-byte-compile setting from some lisp/language files= . > >>=20 > >> My gut tells me this is just a trigger but not the cause of the = bug :-( > > > > What could be the cause, given that this commit triggers it? >=20 > Perhaps some constant sharing that the byte compiler introduces? Maybe. But based on the evidence below, and also on the fact that th= e problem is so elusive and behaves like a classical heisenbug, my firs= t suspicion is elsewhere. After trying a few tricks, I succeeded to catch the bug in GDB. (The full backtrace is near the end of this message.) Here's what I found= . First, this really happens while cus-dep.el scans ethio-util.el. The Lisp call which throws the error is this: (re-search-forward =09=09 (concat "(provide[ \t\n]+\\('\\|(quote[ \t\n]\\)[ \t\n]*" =09=09=09 (regexp-quote name) "[ \t\n)]") =09=09 nil t)) What I see on the C level is this: (gdb) bt #0 xsignal2 (error_symbol=3D56891898, arg1=3D56963794, arg2=3D1678= 1132) at eval.c:1740 #1 0x01024a51 in wrong_type_argument (predicate=3D56891898, value= =3D16781132) at data.c:111 #2 0x0102b4e8 in Faref (array=3D61843973, idx=3D16781132) at data.= c:2090 #3 0x0129e66e in char_table_translate (table=3D61843973, ch=3D4195= 283) at chartab.c:680 #4 0x01142f6a in re_search_2 (bufp=3D0x1933c00, str1=3D0x10757948 "\002=E2=95=98=E2=8C=90\002\303=C2=BF\002\312= \212\002\307=E2=95=96\002\333=C2=BC\002\334=D7=A7\002\341\214\217= =C3=9F\002\341\214\216=C3=9F\002\303=E2=96=92\002=E2=95=98=E2=95=97\0= 02\341\214\215=C3=9F\002\303=E2=95=97\002\341\214\214=C3=9F\002\341\2= 14=C3=9F=D7=9B\002\305=E2=8C=90\002\307=D7=A2\002\305=E2=94=90\002\30= 7=D7=97\002\305=C2=BF\002\305\262\002\303=D7=A6\002\306\263\002\341\2= 14\212=C3=9F\002\341\214=C3=9F=D7=99\002\303\220", size1=3D51024, str2=3D0x1077fb17
, size2=3D0, startpos=3D23749, range=3D27240, regs=3D0x19351f0, stop=3D51024= ) at regex.c:4422 #5 0x010fbd70 in search_buffer (string=3D272417249, pos=3D1, pos_b= yte=3D1, lim=3D48448, lim_byte=3D51025, n=3D1, RE=3D1, trt=3D61843973, i= nverse_trt=3D61841925, posix=3D0) at search.c:1205 #6 0x010fb578 in search_command (string=3D272417249, bound=3D56838= 170, noerror=3D56838194, count=3D56838170, direction=3D1, RE=3D1, po= six=3D0) at search.c:997 #7 0x010fef92 in Fre_search_forward (regexp=3D272417249, bound= =3D56838170, noerror=3D56838194, count=3D56838170) at search.c:2162 (gdb) fr 7 #7 0x010fef92 in Fre_search_forward (regexp=3D272417249, bound= =3D56838170, noerror=3D56838194, count=3D56838170) at search.c:2162 2162 return search_command (regexp, bound, noerror, count, 1, = 1, 0); (gdb) p regexp $9 =3D 272417249 (gdb) xstring $10 =3D (struct Lisp_String *) 0x103cc1e0 "(provide[=09 \n]+\\('\\|(quote[=09 \n]\\)[=09 \n]*ethio-util[=09 \= n)]" (gdb) fr 3 #3 0x0129e66e in char_table_translate (table=3D61843973, ch=3D4195= 283) at chartab.c:680 680 value =3D Faref (table, make_number (ch)); (gdb) p table $11 =3D 61843973 (gdb) xtype Lisp_Vectorlike PVEC_CHAR_TABLE (gdb) xchartable $12 =3D (struct Lisp_Char_Table *) 0x3afaa00 Purpose: "case-table" 3 extra slots (gdb) p current_buffer->text->beg $13 =3D ( unsigned char *) 0x10744948 ";;; ethio-util.el --- utilities fo= r Ethiopic -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-199= 8, 2002-2012 Free Software Foundation, Inc.\n;; Copyright (C) 1997, = 1998, 1999, 2000, 2001, 2002, 20"... (gdb) p current_buffer->pt $14 =3D 1 So we are searching from buffer beginning, and the buffer text looks perfectly OK. But look what "text" is regex.c trying to search: #4 0x01142f6a in re_search_2 (bufp=3D0x1933c00, str1=3D0x10757948 "\002=E2=95=98=E2=8C=90\002\303=C2=BF\002\312\2= 12\002\307=E2=95=96\002\333=C2=BC\002\334=D7=A7\002\341\214\217=C3= =9F\002\341\214\216=C3=9F\002\303=E2=96=92\002=E2=95=98=E2=95=97\002\= 341\214\215=C3=9F\002\303=E2=95=97\002\341\214\214=C3=9F\002\341\214= =C3=9F=D7=9B\002\305=E2=8C=90\002\307=D7=A2\002\305=E2=94=90\002\307= =D7=97\002\305=C2=BF\002\305\262\002\303=D7=A6\002\306\263\002\341\21= 4\212=C3=9F\002\341\214=C3=9F=D7=99\002\303\220", size1=3D51024, str2=3D0x1077fb17
, size2=3D0, startpos=3D23749, range=3D27240, regs=3D0x19351f0, stop=3D51024) = at regex.c:4422 Total garbage. So I think that what happened is that something, probably the translation through a char-table, caused allocation of a large chunk of memory, which in turn relocated the text of the current buffer behind regex.c's back, which still uses C pointers to the old locatio= n of the buffer text. Here's how search.c calls re_search_2: p1 =3D BEGV_ADDR; s1 =3D GPT_BYTE - BEGV_BYTE; p2 =3D GAP_END_ADDR; s2 =3D ZV_BYTE - GPT_BYTE; if (s1 < 0) =09{ =09 p2 =3D p1; =09 s2 =3D ZV_BYTE - BEGV_BYTE; =09 s1 =3D 0; =09} if (s2 < 0) =09{ =09 s1 =3D ZV_BYTE - BEGV_BYTE; =09 s2 =3D 0; =09} re_match_object =3D Qnil; while (n < 0) =09{ =09 EMACS_INT val; =09 val =3D re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, =09=09=09 pos_byte - BEGV_BYTE, lim_byte - pos_byte, =09=09=09 (NILP (Vinhibit_changing_match_data) =09=09=09 ? &search_regs : &search_regs_1), =09=09=09 /* Don't allow match past current point */ =09=09=09 pos_byte - BEGV_BYTE); We pass s1 and s2, which are pointers to buffer text, so if buffer text is relocated, we are screwed. Does this explanation sound reasonable? If so, any ideas how to fix this? Here's the full backtrace: #0 xsignal2 (error_symbol=3D56891898, arg1=3D56963794, arg2=3D1678= 1132) at eval.c:1740 #1 0x01024a51 in wrong_type_argument (predicate=3D56891898, value= =3D16781132) at data.c:111 #2 0x0102b4e8 in Faref (array=3D61843973, idx=3D16781132) at data.= c:2090 #3 0x0129e66e in char_table_translate (table=3D61843973, ch=3D4195= 283) at chartab.c:680 #4 0x01142f6a in re_search_2 (bufp=3D0x1933c00, str1=3D0x10757948 "\002=E2=95=98=E2=8C=90\002\303=C2=BF\002\312= \212\002\307=E2=95=96\002\333=C2=BC\002\334=D7=A7\002 341\214\\217= =C3=9F\002\341\214\216=C3=9F\002\303=E2=96=92\002=E2=95=98=E2=95=97\0= 02\341\214\215=C3=9F\002\303=E2=95=97\002\341\214\214=C3=9F\002\341\2= 14=C3=9F=D7=9B\002\305=E2=8C=90\002\307=D7=A2\002\305=E2=94=90\002\30= 7=D7=97\002\305=C2=BF\002\305\262\002\303=D7=A6\002\306\263\002\341\2= 14\212=C3=9F\002\341\214=C3=9F=D7=99\002\303\220", size1=3D51024, str2=3D0x1077fb17
, size2=3D0, startpos=3D23749, range=3D27240, regs=3D0x19351f0, stop=3D51024= ) at regex.c:4422 #5 0x010fbd70 in search_buffer (string=3D272417249, pos=3D1, pos_b= yte=3D1, lim=3D48448, lim_byte=3D51025, n=3D1, RE=3D1, trt=3D61843973, i= nverse_trt=3D61841925, posix=3D0) at search.c:1205 #6 0x010fb578 in search_command (string=3D272417249, bound=3D56838= 170, noerror=3D56838194, count=3D56838170, direction=3D1, RE=3D1, po= six=3D0) at search.c:997 #7 0x010fef92 in Fre_search_forward (regexp=3D272417249, bound= =3D56838170, noerror=3D56838194, count=3D56838170) at search.c:2162 #8 0x01036e84 in Ffuncall (nargs=3D4, args=3D0x82df40) at eval.c:2= 946 #9 0x011236db in exec_byte_code (bytestr=3D66621569, vector=3D6281= 8821, maxdepth=3D32, args_template=3D56838170, nargs=3D0, args=3D0x0)= at bytecode.c:785 #10 0x01037c4e in funcall_lambda (fun=3D61992805, nargs=3D0, arg_ve= ctor=3D0x82e1b4) at eval.c:3166 #11 0x0103712c in Ffuncall (nargs=3D1, args=3D0x82e1b0) at eval.c:2= 984 #12 0x01034c3c in eval_sub (form=3D59285366) at eval.c:2255 #13 0x01030431 in Fprogn (args=3D59285382) at eval.c:364 #14 0x010302b1 in Fif (args=3D59285334) at eval.c:315 #15 0x01034986 in eval_sub (form=3D59285310) at eval.c:2231 #16 0x01030431 in Fprogn (args=3D59285390) at eval.c:364 #17 0x01030389 in Fcond (args=3D59285398) at eval.c:342 #18 0x01034986 in eval_sub (form=3D59284782) at eval.c:2231 #19 0x01030431 in Fprogn (args=3D59309078) at eval.c:364 #20 0x01031bb3 in FletX (args=3D59286038) at eval.c:983 #21 0x01034986 in eval_sub (form=3D59285950) at eval.c:2231 #22 0x01030431 in Fprogn (args=3D59309158) at eval.c:364 #23 0x010320db in Fwhile (args=3D59285942) at eval.c:1075 #24 0x01034986 in eval_sub (form=3D59285934) at eval.c:2231 #25 0x01030431 in Fprogn (args=3D59309166) at eval.c:364 #26 0x01032044 in Flet (args=3D59285606) at eval.c:1053 #27 0x01034986 in eval_sub (form=3D59245286) at eval.c:2231 #28 0x01030431 in Fprogn (args=3D62798582) at eval.c:364 #29 0x01034986 in eval_sub (form=3D62798590) at eval.c:2231 #30 0x01030291 in Fif (args=3D62798606) at eval.c:314 #31 0x01034986 in eval_sub (form=3D62798614) at eval.c:2231 #32 0x0103530e in eval_sub (form=3D59245270) at eval.c:2344 #33 0x01030431 in Fprogn (args=3D59309182) at eval.c:364 #34 0x01032044 in Flet (args=3D59245262) at eval.c:1053 #35 0x01034986 in eval_sub (form=3D59245198) at eval.c:2231 #36 0x01030431 in Fprogn (args=3D59308166) at eval.c:364 #37 0x01037b1a in funcall_lambda (fun=3D59308190, nargs=3D1, arg_ve= ctor=3D0x82f1c0) at eval.c:3159 #38 0x01037461 in apply_lambda (fun=3D59308198, args=3D59276566) at= eval.c:3043 #39 0x0103533d in eval_sub (form=3D59276590) at eval.c:2347 #40 0x01030431 in Fprogn (args=3D59276558) at eval.c:364 #41 0x01037b1a in funcall_lambda (fun=3D59275998, nargs=3D0, arg_ve= ctor=3D0x82f420) at eval.c:3159 #42 0x01037461 in apply_lambda (fun=3D59275990, args=3D56838170) at= eval.c:3043 #43 0x0103533d in eval_sub (form=3D59187782) at eval.c:2347 #44 0x0103263c in Funwind_protect (args=3D59187766) at eval.c:1304 #45 0x01034986 in eval_sub (form=3D59187790) at eval.c:2231 #46 0x01030431 in Fprogn (args=3D59181374) at eval.c:364 #47 0x01032044 in Flet (args=3D59187798) at eval.c:1053 #48 0x01034986 in eval_sub (form=3D59187830) at eval.c:2231 #49 0x01030431 in Fprogn (args=3D59181366) at eval.c:364 #50 0x010302b1 in Fif (args=3D59066374) at eval.c:315 #51 0x01034986 in eval_sub (form=3D59066382) at eval.c:2231 #52 0x01030431 in Fprogn (args=3D59210614) at eval.c:364 #53 0x01037b1a in funcall_lambda (fun=3D59210590, nargs=3D0, arg_ve= ctor=3D0x82fb30) at eval.c:3159 #54 0x01037461 in apply_lambda (fun=3D59210582, args=3D56838170) at= eval.c:3043 #55 0x0103533d in eval_sub (form=3D58576574) at eval.c:2347 #56 0x0103450f in Feval (form=3D58576574, lexical=3D56838170) at ev= al.c:2137 #57 0x01005123 in top_level_2 () at keyboard.c:1169 #58 0x01032ab9 in internal_condition_case (bfun=3D0x1005107 , handlers=3D56891826, hfun=3D0x1004cba ) at eval.c:14= 48 #59 0x01005155 in top_level_1 (ignore=3D56838170) at keyboard.c:117= 7 #60 0x0103247c in internal_catch (tag=3D56889874, func=3D0x1005125 = , arg=3D56838170) at eval.c:1205 #61 0x01005090 in command_loop () at keyboard.c:1132 #62 0x01004678 in recursive_edit_1 () at keyboard.c:759 #63 0x0100499a in Frecursive_edit () at keyboard.c:823 #64 0x010027c9 in main (argc=3D39, argv=3D0xa34058) at emacs.c:1711 Lisp Backtrace: "re-search-forward" (0x82df44) "custom-make-dependencies" (0x82e1b4) "funcall" (0x82e1b0) "if" (0x82e430) "cond" (0x82e5c0) "let*" (0x82e790) "while" (0x82e930) "let" (0x82eb40) "progn" (0x82ec90) "if" (0x82ede0) "when" (0x82eef0) "let" (0x82f0f0) "command-line-1" (0x82f1c0) "command-line" (0x82f420) "unwind-protect" (0x82f6d0) "let" (0x82f8d0) "if" (0x82fa60) "normal-top-level" (0x82fb30) From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 May 2012 20:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, Andreas Schwab , 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13376328632531 (code B ref 11519); Mon, 21 May 2012 20:42:02 +0000 Received: (at 11519) by debbugs.gnu.org; 21 May 2012 20:41:03 +0000 Received: from localhost ([127.0.0.1]:37666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWZPa-0000ek-Fs for submit@debbugs.gnu.org; Mon, 21 May 2012 16:41:02 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:14656) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWZPF-0000dx-RU for 11519@debbugs.gnu.org; Mon, 21 May 2012 16:41:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMAh0/O+K+j/2dsb2JhbAA3o0KBCIF1AQEEAVYjBQsLNBIUGA0kiBOiEYt2DBUICzoMA4M+A4NwBKNjhFg X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="181653192" Received: from 206-248-175-163.dsl.teksavvy.com (HELO pastel.home) ([206.248.175.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 21 May 2012 16:39:56 -0400 Received: by pastel.home (Postfix, from userid 20848) id 13F8C597A9; Mon, 21 May 2012 16:39:56 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> Date: Mon, 21 May 2012 16:39:56 -0400 In-Reply-To: <83vcjpxw18.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 May 2012 20:51:15 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > So I think that what happened is that something, probably the > translation through a char-table, caused allocation of a large chunk > of memory, which in turn relocated the text of the current buffer > behind regex.c's back, which still uses C pointers to the old location > of the buffer text. Here's how search.c calls re_search_2: > p1 = BEGV_ADDR; > s1 = GPT_BYTE - BEGV_BYTE; > p2 = GAP_END_ADDR; > s2 = ZV_BYTE - GPT_BYTE; > if (s1 < 0) > { > p2 = p1; > s2 = ZV_BYTE - BEGV_BYTE; > s1 = 0; > } > if (s2 < 0) > { > s1 = ZV_BYTE - BEGV_BYTE; > s2 = 0; > } > re_match_object = Qnil; > while (n < 0) > { > EMACS_INT val; > val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, > pos_byte - BEGV_BYTE, lim_byte - pos_byte, > (NILP (Vinhibit_changing_match_data) > ? &search_regs : &search_regs_1), > /* Don't allow match past current point */ > pos_byte - BEGV_BYTE); > We pass s1 and s2, which are pointers to buffer text, so if buffer > text is relocated, we are screwed. > Does this explanation sound reasonable? If so, any ideas how to fix > this? I suggest you let-bind some witness variable is re_search_2 and then in the buffer-relocation code, you test this var and abort if it's non-nil. That should let us catch the offender red-handed, after which we will know better how to fix the problem. Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping References: Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 May 2012 14:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: lekktu@gmail.com, schwab@linux-m68k.org, 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133769760011221 (code B ref 11519); Tue, 22 May 2012 14:40:02 +0000 Received: (at 11519) by debbugs.gnu.org; 22 May 2012 14:40:00 +0000 Received: from localhost ([127.0.0.1]:38926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWqFk-0002uw-Aw for submit@debbugs.gnu.org; Tue, 22 May 2012 10:40:00 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:37673 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWqFO-0002uP-K2 for 11519@debbugs.gnu.org; Tue, 22 May 2012 10:39:57 -0400 Received: from 126.229.accsnet.ne.jp ([202.220.229.126]:49786 helo=ubuntu) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SWqEe-0007jj-1G; Tue, 22 May 2012 10:38:52 -0400 From: Kenichi Handa In-Reply-To: <83vcjpxw18.fsf@gnu.org> (message from Eli Zaretskii on Mon, 21 May 2012 20:51:15 +0300) Date: Tue, 22 May 2012 23:38:34 +0900 Message-ID: <87bolg5lhx.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) In article <83vcjpxw18.fsf@gnu.org>, Eli Zaretskii writes: > So I think that what happened is that something, probably the > translation through a char-table, caused allocation of a large chunk > of memory, which in turn relocated the text of the current buffer > behind regex.c's back, which still uses C pointers to the old location > of the buffer text. The function char_table_translate may allocate some amount of memory. But that's only when the char-table is one of a "unicode character property table" loaded via the function uniprop_table. When char_table_translate is called from re_search_2 (via the macro RE_TRANSLATE), the char-table to lookup is one of a case-related table (equiv? canon?) which is not a unicode property table. The function that acutally allocates memory via. char_table_translate is uniprop_table_uncompress. --- Kenichi Handa handa@m17n.org From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 May 2012 19:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Kenichi Handa Cc: lekktu@gmail.com, schwab@linux-m68k.org, 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13377133133108 (code B ref 11519); Tue, 22 May 2012 19:02:02 +0000 Received: (at 11519) by debbugs.gnu.org; 22 May 2012 19:01:53 +0000 Received: from localhost ([127.0.0.1]:39280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWuLA-0000o4-GA for submit@debbugs.gnu.org; Tue, 22 May 2012 15:01:53 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:61655) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWuL7-0000nr-KI for 11519@debbugs.gnu.org; Tue, 22 May 2012 15:01:51 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M4F00300U4IWF00@a-mtaout23.012.net.il> for 11519@debbugs.gnu.org; Tue, 22 May 2012 22:00:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4F003T2U4ZW700@a-mtaout23.012.net.il>; Tue, 22 May 2012 22:00:36 +0300 (IDT) Date: Tue, 22 May 2012 22:00:46 +0300 From: Eli Zaretskii In-reply-to: Message-id: <83k404xcpt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Andreas Schwab , lekktu@gmail.com, 115= 19@debbugs.gnu.org > Date: Mon, 21 May 2012 16:39:56 -0400 >=20 > I suggest you let-bind some witness variable is re_search_2 and the= n in > the buffer-relocation code, you test this var and abort if it's non= -nil. > That should let us catch the offender red-handed, after which we wi= ll > know better how to fix the problem. I did the equivalent of the above, but without changing the source (t= o minimize the chances that the bug will disappear). Is the evidence below conclusive enough? Breakpoint 3, search_buffer (string=3D272417249, pos=3D1, pos_byte= =3D1, lim=3D48448, lim_byte=3D51025, n=3D1, RE=3D1, trt=3D61843973, inverse_trt= =3D61841925, posix=3D0) at search.c:1206 1206 val =3D re_search_2 (bufp, (char *) p1, s1, (char= *) p2, s2, $1771 =3D 272417249 $1772 =3D (struct Lisp_String *) 0x103cc1e0 "(provide[ =09\n]+\\('\\|(quote[ =09\n]\\)[ =09\n]*ethio-util[ = =09\n)]" (gdb) p current_buffer->text->beg $1773 =3D ( unsigned char *) 0x10757948 ";;; ethio-util.el --- utilities fo= r Ethiopic -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-1998= , 2002-2012 Free Software Foundation, Inc.\n;; Copyright (C) 1997, 1= 998, 1999, 2000, 2001, 2002, 20"... (gdb) p *p1@20 $1774 =3D ";;; ethio-util.el --" (gdb) p p1 $1775 =3D ( unsigned char *) 0x10757948 ";;; ethio-util.el --- utilities fo= r Ethiopic -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-1998= , 2002-2012 Free Software Foundation, Inc.\n;; Copyright (C) 1997, 1= 998, 1999, 2000, 2001, 2002, 20"... So at this point, before we call re_search_2, p1 and current_buffer->text->beg point to the same memory. Now: (gdb) watch current_buffer->text->beg Hardware watchpoint 4: current_buffer->text->beg (gdb) c Continuing. Hardware watchpoint 4: current_buffer->text->beg Old value =3D (unsigned char *) 0x10757948 ";;; ethio-util.el --- utilities f= or Ethiopic -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-1998, 2002-20= 12 Free Soft ware Foundation, Inc.\n;; Copyright (C) 1997, 1998, 1999, 2000, 200= 1, 2002, 20". .. New value =3D (unsigned char *) 0x10826948 ";;; ethio-util.el --- utilities f= or Ethiopic -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-1998, 2002-20= 12 Free Soft ware Foundation, Inc.\n;; Copyright (C) 1997, 1998, 1999, 2000, 200= 1, 2002, 20"... r_alloc_sbrk (size=3D847872) at ralloc.c:808 808 for (b =3D last_bloc; b !=3D NIL_BLOC; b =3D b->p= rev) Note that the address of buffer text has changed from 0x10757948 to 0x10826948. And the culprit is ... (gdb) bt #0 r_alloc_sbrk (size=3D847872) at ralloc.c:808 #1 0x012e9dc0 in get_contiguous_space (size=3D847872, position= =3D0x10748000) at gmalloc.c:447 #2 0x012ea662 in _malloc_internal_nolock (size=3D786436) at gmallo= c.c:821 #3 0x012eaa4c in _malloc_internal (size=3D786436) at gmalloc.c:904 #4 0x012eaa99 in e_malloc (size=3D786436) at gmalloc.c:927 #5 0x0103a3b2 in emacs_blocked_malloc (size=3D786436, ptr=3D0x0) a= t alloc.c:1308 #6 0x012eaa99 in e_malloc (size=3D786436) at gmalloc.c:927 #7 0x010397fb in xmalloc (size=3D786436) at alloc.c:727 #8 0x0120da2d in load_charset_map_from_file (charset=3D0x1944970, mapfile=3D57455953, control_flag=3D1) at charset.c:501 #9 0x0120e480 in load_charset (charset=3D0x1944970, control_flag= =3D1) at charset.c:646 #10 0x01214cc9 in maybe_unify_char (c=3D1704385, val=3D57027682) at= charset.c:1644 #11 0x0128b4a0 in string_char ( p=3D0x1075d630 " 2.=C3=B7=C3=A1=D7=97=D7=92 3.=C3=B7=C3=A1= =D7=97=D7=93 4.=C3=B7=C3=A1=D7=97=D7=94 5.=C3=B7=C3=A1=D7=97\200\")= \n (cond\n ((=3D arg ?1)\n (insert \"=C3=B7=C3=A1=D7=97\201\"))= \n ((=3D arg ?2)\n (insert \"=C3=B7=C3=A1=D7=97=D7=92\"))\n ((= =3D arg ?3)\n (insert \"=C3=B7=C3=A1=D7=97=D7=93\"))\n ((=3D arg= ?4)\n (insert \"=C3=B7=C3=A1=D7=97=D7=94\"))\n ((=3D arg ?5"...= , advanced=3D0x0, len=3D0x82dcec) at character.c:200 #12 0x01142f65 in re_search_2 (bufp=3D0x1933c08, str1=3D0x10757948 ";;; ethio-util.el --- utilities for Ethiopic= -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-1998, 20= 02-2012 Free Software Foundation, Inc.\n;; Copyright (C) 1997, 1998,= 1999, 2000, 2001, 2002, 20"..., size1=3D51024, str2=3D0x1077fb17 "", size2=3D0, startpos=3D2374= 9, range=3D27244, regs=3D0x19351f8, stop=3D51024) at regex.c:4421 #13 0x010fbd78 in search_buffer (string=3D272417249, pos=3D1, pos_b= yte=3D1, lim=3D48448, lim_byte=3D51025, n=3D1, RE=3D1, trt=3D61843973, i= nverse_trt=3D61841925, posix=3D0) at search.c:1207 #14 0x010fb578 in search_command (string=3D272417249, bound=3D56838= 170, noerror=3D56838194, count=3D56838170, direction=3D1, RE=3D1, po= six=3D0) at search.c:997 #15 0x010fefa4 in Fre_search_forward (regexp=3D272417249, bound= =3D56838170, noerror=3D56838194, count=3D56838170) at search.c:2165 The fragment of regex.c that triggers this is as follows: =09 if (RE_TRANSLATE_P (translate)) =09=09{ =09=09 if (multibyte) =09=09 while (range > lim) =09=09 { =09=09=09int buf_charlen; >>>>>>>>>>>>>>>>>=09buf_ch =3D STRING_CHAR_AND_LENGTH (d, buf_cha= rlen); =09=09=09buf_ch =3D RE_TRANSLATE (translate, buf_ch); =09=09=09if (fastmap[CHAR_LEADING_CODE (buf_ch)]) =09=09=09 break; =09=09=09range -=3D buf_charlen; =09=09=09d +=3D buf_charlen; =09=09 } The marked line calls string_char, which calls maybe_unify_char, whic= h calls load_charset, which causes memory allocation and relocation of buffer text. The very next call to RE_TRANSLATE, which calls char_table_translate, throws an error because buf_ch is garbage. If you agree with the diagnosis, then how about the change below? It fixes the problem for me. (Or is there a better way?) If accepted, = I will add the necessary commentary to this code and a prototype for th= e new function. In any case, I suggest to install the fix on the emacs-24 branch, because this issue is a disaster waiting to happen. =3D=3D=3D modified file 'src/ralloc.c' --- src/ralloc.c=092012-04-16 01:18:13 +0000 +++ src/ralloc.c=092012-05-22 18:39:25 +0000 @@ -1143,6 +1143,12 @@ r_alloc_reset_variable (POINTER *old, PO bloc->variable =3D new; } =20 +void +r_alloc_inhibit_buffer_relocation (int inhibit) +{ + use_relocatable_buffers =3D (inhibit ? 0 : 1); +} + =0C /*******************************************************************= **** =09=09=09 Initialization =3D=3D=3D modified file 'src/search.c' --- src/search.c=092012-05-17 00:03:49 +0000 +++ src/search.c=092012-05-22 18:41:23 +0000 @@ -1158,12 +1158,19 @@ search_buffer (Lisp_Object string, EMACS while (n < 0) =09{ =09 EMACS_INT val; + +#ifdef REL_ALLOC +=09 r_alloc_inhibit_buffer_relocation (1); +#endif =09 val =3D re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, =09=09=09 pos_byte - BEGV_BYTE, lim_byte - pos_byte, =09=09=09 (NILP (Vinhibit_changing_match_data) =09=09=09 ? &search_regs : &search_regs_1), =09=09=09 /* Don't allow match past current point */ =09=09=09 pos_byte - BEGV_BYTE); +#ifdef REL_ALLOC +=09 r_alloc_inhibit_buffer_relocation (0); +#endif =09 if (val =3D=3D -2) =09 { =09 matcher_overflow (); @@ -1202,11 +1209,18 @@ search_buffer (Lisp_Object string, EMACS while (n > 0) =09{ =09 EMACS_INT val; + +#ifdef REL_ALLOC +=09 r_alloc_inhibit_buffer_relocation (1); +#endif =09 val =3D re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, =09=09=09 pos_byte - BEGV_BYTE, lim_byte - pos_byte, =09=09=09 (NILP (Vinhibit_changing_match_data) =09=09=09 ? &search_regs : &search_regs_1), =09=09=09 lim_byte - BEGV_BYTE); +#ifdef REL_ALLOC +=09 r_alloc_inhibit_buffer_relocation (0); +#endif =09 if (val =3D=3D -2) =09 { =09 matcher_overflow (); From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 May 2012 19:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Kenichi Handa Cc: lekktu@gmail.com, schwab@linux-m68k.org, 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13377133743202 (code B ref 11519); Tue, 22 May 2012 19:03:02 +0000 Received: (at 11519) by debbugs.gnu.org; 22 May 2012 19:02:54 +0000 Received: from localhost ([127.0.0.1]:39285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWuMA-0000pa-8L for submit@debbugs.gnu.org; Tue, 22 May 2012 15:02:54 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:57985) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWuM8-0000pO-43 for 11519@debbugs.gnu.org; Tue, 22 May 2012 15:02:52 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4F00I00TZJII00@a-mtaout22.012.net.il> for 11519@debbugs.gnu.org; Tue, 22 May 2012 22:02:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4F00HW0U7BNNC0@a-mtaout22.012.net.il>; Tue, 22 May 2012 22:02:01 +0300 (IDT) Date: Tue, 22 May 2012 22:02:09 +0300 From: Eli Zaretskii In-reply-to: <87bolg5lhx.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83ipfoxcni.fsf@gnu.org> References: <87bolg5lhx.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Kenichi Handa > Cc: schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Tue, 22 May 2012 23:38:34 +0900 > > In article <83vcjpxw18.fsf@gnu.org>, Eli Zaretskii writes: > > > So I think that what happened is that something, probably the > > translation through a char-table, caused allocation of a large chunk > > of memory, which in turn relocated the text of the current buffer > > behind regex.c's back, which still uses C pointers to the old location > > of the buffer text. > > The function char_table_translate may allocate some amount > of memory. But that's only when the char-table is one of a > "unicode character property table" loaded via the function > uniprop_table. When char_table_translate is called from > re_search_2 (via the macro RE_TRANSLATE), the char-table to > lookup is one of a case-related table (equiv? canon?) which > is not a unicode property table. You are right: it was not char_table_translate, it was load_charset_map_from_file, invoked through STRING_CHAR_AND_LENGTH. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 May 2012 19:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Kenichi Handa , schwab@linux-m68k.org, 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13377144624825 (code B ref 11519); Tue, 22 May 2012 19:22:01 +0000 Received: (at 11519) by debbugs.gnu.org; 22 May 2012 19:21:02 +0000 Received: from localhost ([127.0.0.1]:39291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWudi-0001Ff-0G for submit@debbugs.gnu.org; Tue, 22 May 2012 15:21:02 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41968) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWudf-0001FL-K6 for 11519@debbugs.gnu.org; Tue, 22 May 2012 15:21:00 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q4MJKDCg028423; Tue, 22 May 2012 15:20:13 -0400 Received: by pastel.home (Postfix, from userid 20848) id D4E51D201C; Tue, 22 May 2012 15:19:12 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> Date: Tue, 22 May 2012 15:19:12 -0400 In-Reply-To: <83k404xcpt.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 22 May 2012 22:00:46 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4229=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4229> : streams <758285> : uri <1115422> X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) > Note that the address of buffer text has changed from 0x10757948 to > 0x10826948. And the culprit is ... > #7 0x010397fb in xmalloc (size=786436) at alloc.c:727 > #8 0x0120da2d in load_charset_map_from_file (charset=0x1944970, > mapfile=57455953, control_flag=1) at charset.c:501 Huh! Indeed, I always assumed that relocation would be something that can only happen during GC, not in a mere xmalloc. > The marked line calls string_char, which calls maybe_unify_char, which > calls load_charset, which causes memory allocation and relocation of > buffer text. This brings up back to the issue of calling maybe_unify_char in STRING_CHAR_AND_LENGTH. One more strike against it. Handa, could you prepare a patch that removes this? > If you agree with the diagnosis, then how about the change below? Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd replace "inhibit ? 0 : 1" with "!inhibit"). But is it really new in Emacs-24? It seems the same problem is already present in Emacs-23, so it's probably not so urgent to fix it for 24.1. > It fixes the problem for me. (Or is there a better way?) If accepted, I > will add the necessary commentary to this code and a prototype for the > new function. In any case, I suggest to install the fix on the > emacs-24 branch, because this issue is a disaster waiting to happen. I wonder: why do we use REL_ALLOC? Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 May 2012 19:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133771613110387 (code B ref 11519); Tue, 22 May 2012 19:49:02 +0000 Received: (at 11519) by debbugs.gnu.org; 22 May 2012 19:48:51 +0000 Received: from localhost ([127.0.0.1]:39337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWv4c-0002hU-NG for submit@debbugs.gnu.org; Tue, 22 May 2012 15:48:50 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:40400) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWv4Z-0002hB-1S for 11519@debbugs.gnu.org; Tue, 22 May 2012 15:48:49 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4F00J00W7L2T00@a-mtaout22.012.net.il> for 11519@debbugs.gnu.org; Tue, 22 May 2012 22:47:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4F00J13WAR1030@a-mtaout22.012.net.il>; Tue, 22 May 2012 22:47:16 +0300 (IDT) Date: Tue, 22 May 2012 22:47:26 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83hav8xak1.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Kenichi Handa , schwab@linux-m68k.org, lekktu@gmail.com, > 11519@debbugs.gnu.org > Date: Tue, 22 May 2012 15:19:12 -0400 > > > Note that the address of buffer text has changed from 0x10757948 to > > 0x10826948. And the culprit is ... > > > #7 0x010397fb in xmalloc (size=786436) at alloc.c:727 > > #8 0x0120da2d in load_charset_map_from_file (charset=0x1944970, > > mapfile=57455953, control_flag=1) at charset.c:501 > > Huh! Indeed, I always assumed that relocation would be something that > can only happen during GC, not in a mere xmalloc. It happens in xmalloc/xrealloc when ralloc.c is used. > > If you agree with the diagnosis, then how about the change below? > > Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd > replace "inhibit ? 0 : 1" with "!inhibit"). But is it really new in > Emacs-24? It seems the same problem is already present in Emacs-23, so > it's probably not so urgent to fix it for 24.1. The problem is indeed not new, but so what? It is real, and it just happened to us in real life, albeit on the trunk. Who knows how many other problems which we dismiss as not reproducible could have been caused by this (especially when exotic character sets were involved)? > I wonder: why do we use REL_ALLOC? AFAIK, we do that only on platforms that don't support mmap for allocating buffer text. The relocatable allocator makes a more efficient use of memory, especially when it is almost full: it can potentially produce a large block from several small ones by moving buffer text around to "compact" their storage. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 00:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@gnu.org, schwab@linux-m68k.org, 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13377341487719 (code B ref 11519); Wed, 23 May 2012 00:50:02 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 00:49:08 +0000 Received: from localhost ([127.0.0.1]:39506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWzlD-00020R-NH for submit@debbugs.gnu.org; Tue, 22 May 2012 20:49:07 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:45020) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SWzkt-0001za-JI for 11519@debbugs.gnu.org; Tue, 22 May 2012 20:49:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu0/O+K+j/2dsb2JhbABEtBGBCIIVAQEEAVYjEAs0EhQYDSQsh3AFugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="181881469" Received: from 206-248-175-163.dsl.teksavvy.com (HELO pastel.home) ([206.248.175.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 May 2012 20:47:55 -0400 Received: by pastel.home (Postfix, from userid 20848) id CA23C58E09; Tue, 22 May 2012 20:47:54 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> Date: Tue, 22 May 2012 20:47:54 -0400 In-Reply-To: <83hav8xak1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 22 May 2012 22:47:26 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > If you agree with the diagnosis, then how about the change below? >> Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd >> replace "inhibit ? 0 : 1" with "!inhibit"). But is it really new in >> Emacs-24? It seems the same problem is already present in Emacs-23, so >> it's probably not so urgent to fix it for 24.1. > The problem is indeed not new, but so what? It is real, and it just > happened to us in real life, albeit on the trunk. Who knows how many > other problems which we dismiss as not reproducible could have been > caused by this (especially when exotic character sets were involved)? I assume that the problem can show up in many other places than re_search, so yes, it's a real problem that we need to fix for real, but your workaround will only fix the problem we happened to bump into, so adding this fix to the emacs-24 branch may be completely useless if this bug never shows up at that place there. >> I wonder: why do we use REL_ALLOC? > AFAIK, we do that only on platforms that don't support mmap for > allocating buffer text. So, IIUC the only reason to use it is so that we can more often return memory to the OS even for the non-mmap case? Is that because returning memory can only be done via sbrk style memory management? I wonder how effective it is in practice. Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 03:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Richard Stallman Cc: handa@gnu.org, schwab@linux-m68k.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133774204519310 (code B ref 11519); Wed, 23 May 2012 03:01:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 03:00:45 +0000 Received: from localhost ([127.0.0.1]:39583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SX1ob-00051O-22 for submit@debbugs.gnu.org; Tue, 22 May 2012 23:00:45 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:44522) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SX1oF-00050p-JS for 11519@debbugs.gnu.org; Tue, 22 May 2012 23:00:43 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4G00N00G931V00@a-mtaout22.012.net.il> for 11519@debbugs.gnu.org; Wed, 23 May 2012 05:59:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4G00NOSGB61K00@a-mtaout22.012.net.il>; Wed, 23 May 2012 05:59:30 +0300 (IDT) Date: Wed, 23 May 2012 05:59:41 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83ehqby542.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: handa@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Tue, 22 May 2012 20:47:54 -0400 > > I assume that the problem can show up in many other places than > re_search, so yes, it's a real problem that we need to fix for real, but > your workaround will only fix the problem we happened to bump into Which other places use C pointers to buffer text and call functions that can allocate memory? If you know about such places, please point them out. I don't think we have them, but that's me. > adding this fix to the emacs-24 branch may be completely useless if this > bug never shows up at that place there. That "if" is profoundly false, as I can now easily craft a use case where it _will_ show up. Anyway, are you against committing this to the release branch? I'd be very sad if you were, having invested so much time in hunting this bug, but I guess I'll survive. > >> I wonder: why do we use REL_ALLOC? > > AFAIK, we do that only on platforms that don't support mmap for > > allocating buffer text. > > So, IIUC the only reason to use it is so that we can more often return > memory to the OS even for the non-mmap case? Is that because returning > memory can only be done via sbrk style memory management? I don't think this is only about _returning_ memory. It is first and foremost about not _asking_ for more memory when we can come up with it by reshuffling buffer text. > I wonder how effective it is in practice. I have no idea. ralloc.c was in place (and used by all platforms) long before I became involved with Emacs. Perhaps Richard can tell. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping References: Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 14:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: lekktu@gmail.com, eliz@gnu.org, schwab@linux-m68k.org, 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133778234517167 (code B ref 11519); Wed, 23 May 2012 14:13:02 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 14:12:25 +0000 Received: from localhost ([127.0.0.1]:40759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXCIa-0004Sq-RZ for submit@debbugs.gnu.org; Wed, 23 May 2012 10:12:25 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:39628 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXCIF-0004SQ-R3 for 11519@debbugs.gnu.org; Wed, 23 May 2012 10:12:22 -0400 Received: from 126.229.accsnet.ne.jp ([202.220.229.126]:54859 helo=ubuntu) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SXCHN-0001ud-8x; Wed, 23 May 2012 10:11:10 -0400 From: Kenichi Handa In-Reply-To: (message from Stefan Monnier on Tue, 22 May 2012 15:19:12 -0400) Date: Wed, 23 May 2012 23:10:51 +0900 Message-ID: <8762bn56ok.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) In article , Stefan Monnier writes: > This brings up back to the issue of calling maybe_unify_char in > STRING_CHAR_AND_LENGTH. One more strike against it. Handa, could you > prepare a patch that removes this? Ok, I'll work on it. But, it's not for 24.1, right? > > If you agree with the diagnosis, then how about the change below? > Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd > replace "inhibit ? 0 : 1" with "!inhibit"). I think it is not just a workaround. If we can suppress buffer/string relocation temporarily, we can utilize that functionality in several other places. --- Kenichi Handa handa@m17n.org From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@gnu.org, schwab@linux-m68k.org, Richard Stallman , 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133778263517635 (code B ref 11519); Wed, 23 May 2012 14:18:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 14:17:15 +0000 Received: from localhost ([127.0.0.1]:40768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXCNH-0004aN-1C for submit@debbugs.gnu.org; Wed, 23 May 2012 10:17:15 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:44104) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXCNF-0004aC-FQ for 11519@debbugs.gnu.org; Wed, 23 May 2012 10:17:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCpYd/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0QAROIHAW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="181969250" Received: from 76-10-150-29.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 May 2012 10:16:18 -0400 Received: by pastel.home (Postfix, from userid 20848) id DF00658C01; Wed, 23 May 2012 10:16:17 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> Date: Wed, 23 May 2012 10:16:17 -0400 In-Reply-To: <83ehqby542.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 May 2012 05:59:41 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Which other places use C pointers to buffer text and call functions > that can allocate memory? IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text is vulnerable to the problem. > Anyway, are you against committing this to the release branch? I'd be > very sad if you were, having invested so much time in hunting this > bug, but I guess I'll survive. I'm not dead set against it, and I'm glad we found the culprit so we can fix it: fixing it on the release branch is not that important, since this bug has been with us since Emacs-23.1, AFAICT. If you really want to install your workaround on the emacs-24 branch, go for it but let's try to find a real fix for the trunk. >> >> I wonder: why do we use REL_ALLOC? >> > AFAIK, we do that only on platforms that don't support mmap for >> > allocating buffer text. >> So, IIUC the only reason to use it is so that we can more often return >> memory to the OS even for the non-mmap case? Is that because returning >> memory can only be done via sbrk style memory management? > I don't think this is only about _returning_ memory. It is first and > foremost about not _asking_ for more memory when we can come up with > it by reshuffling buffer text. So you're saying it's use for fragmentation reasons? But on other platforms where we use mmap, we do suffer from this fragmentation, and yet it doesn't seem to be a real source of problem. That's why I think the only real reason is because memory can only be returned via sbrk-style memory management (i.e. only free memory at the end of the heap can be returned). Is that right? I guess my question turns into "why do we use gmalloc.c instead of a malloc library that uses mmap (or some other mechanism that lets it return large free chunks to the OS)"? AFAIK, Windows is pretty much the only system where we use gmalloc.c and ralloc.c nowadays. Does anyone remember why we don't use the system malloc under Windows (and Cygwin)? Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 15:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: lekktu@gmail.com, Eli Zaretskii , schwab@linux-m68k.org, Richard Stallman , 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133778666923599 (code B ref 11519); Wed, 23 May 2012 15:25:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 15:24:29 +0000 Received: from localhost ([127.0.0.1]:40802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXDQL-00068a-FZ for submit@debbugs.gnu.org; Wed, 23 May 2012 11:24:29 -0400 Received: from granite1.mail.cornell.edu ([128.253.83.141]:35014 helo=authusersmtp.mail.cornell.edu) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXDQJ-00068S-HU for 11519@debbugs.gnu.org; Wed, 23 May 2012 11:24:28 -0400 Received: from [192.168.1.4] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id q4NFNZNQ002237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 May 2012 11:23:36 -0400 (EDT) Message-ID: <4FBD00E9.1060401@cornell.edu> Date: Wed, 23 May 2012 11:23:21 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-CORNELL-SPAM-CHECKED: Pawpaw X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.23.150915 X-Original-Sender: kbrown@cornell.edu - Wed May 23 11:23:37 2012 X-PMX-CORNELL-REASON: CU_White_List_Override X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On 5/23/2012 10:16 AM, Stefan Monnier wrote: >> Which other places use C pointers to buffer text and call functions >> that can allocate memory? > > IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text is > vulnerable to the problem. > >> Anyway, are you against committing this to the release branch? I'd be >> very sad if you were, having invested so much time in hunting this >> bug, but I guess I'll survive. > > I'm not dead set against it, and I'm glad we found the culprit so we can > fix it: fixing it on the release branch is not that important, since this > bug has been with us since Emacs-23.1, AFAICT. > > If you really want to install your workaround on the emacs-24 branch, go > for it but let's try to find a real fix for the trunk. > >>>>> I wonder: why do we use REL_ALLOC? >>>> AFAIK, we do that only on platforms that don't support mmap for >>>> allocating buffer text. >>> So, IIUC the only reason to use it is so that we can more often return >>> memory to the OS even for the non-mmap case? Is that because returning >>> memory can only be done via sbrk style memory management? >> I don't think this is only about _returning_ memory. It is first and >> foremost about not _asking_ for more memory when we can come up with >> it by reshuffling buffer text. > > So you're saying it's use for fragmentation reasons? > But on other platforms where we use mmap, we do suffer from this > fragmentation, and yet it doesn't seem to be a real source of problem. > That's why I think the only real reason is because memory can only be > returned via sbrk-style memory management (i.e. only free memory at the > end of the heap can be returned). Is that right? > > I guess my question turns into "why do we use gmalloc.c instead of > a malloc library that uses mmap (or some other mechanism that lets it > return large free chunks to the OS)"? > > AFAIK, Windows is pretty much the only system where we use gmalloc.c and > ralloc.c nowadays. Does anyone remember why we don't use the system > malloc under Windows (and Cygwin)? Cygwin uses gmalloc.c but not ralloc.c; it uses mmap for buffers. There are two reasons for using gmalloc.c on Cygwin. The first, which may or may not be important, is that Cygwin's malloc doesn't support __after_morecore_hook, malloc_get_state, or malloc_set_state. The second has to do with the way emacs is dumped on Cygwin. See the comment starting at line 302 in gmalloc.c. I would love to find a better way to deal with this and be able to use the system malloc on Cygwin. Ken From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 15:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Kenichi Handa Cc: lekktu@gmail.com, eliz@gnu.org, schwab@linux-m68k.org, 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133778689523928 (code B ref 11519); Wed, 23 May 2012 15:29:02 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 15:28:15 +0000 Received: from localhost ([127.0.0.1]:40808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXDTz-0006Dt-36 for submit@debbugs.gnu.org; Wed, 23 May 2012 11:28:15 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:8692) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXDTx-0006Dg-Cm for 11519@debbugs.gnu.org; Wed, 23 May 2012 11:28:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCpYd/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOjM4FYgwWBOho X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="181987501" Received: from 76-10-150-29.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 May 2012 11:27:17 -0400 Received: by pastel.home (Postfix, from userid 20848) id D5F9458C01; Wed, 23 May 2012 11:27:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8762bn56ok.fsf@gnu.org> Date: Wed, 23 May 2012 11:27:16 -0400 In-Reply-To: <8762bn56ok.fsf@gnu.org> (Kenichi Handa's message of "Wed, 23 May 2012 23:10:51 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> This brings up back to the issue of calling maybe_unify_char in >> STRING_CHAR_AND_LENGTH. One more strike against it. Handa, could you >> prepare a patch that removes this? > Ok, I'll work on it. Thanks. > But, it's not for 24.1, right? Right, it's for 24.2, so it's not super urgent. >> > If you agree with the diagnosis, then how about the change below? >> Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd >> replace "inhibit ? 0 : 1" with "!inhibit"). > I think it is not just a workaround. If we can suppress buffer/string > relocation temporarily, we can utilize that functionality in several > other places. We could suppress relocation all the time. After all, we don't use relalloc on GNU systems and under Mac OS X. Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 16:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133779200831588 (code B ref 11519); Wed, 23 May 2012 16:54:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 16:53:28 +0000 Received: from localhost ([127.0.0.1]:40846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXEoR-0008DQ-DS for submit@debbugs.gnu.org; Wed, 23 May 2012 12:53:27 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:36096) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXEo6-0008Ca-O6 for 11519@debbugs.gnu.org; Wed, 23 May 2012 12:53:26 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4H00B00IQYUC00@a-mtaout20.012.net.il> for 11519@debbugs.gnu.org; Wed, 23 May 2012 19:52:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4H00A3PIUWPZG0@a-mtaout20.012.net.il>; Wed, 23 May 2012 19:52:09 +0300 (IDT) Date: Wed, 23 May 2012 19:52:21 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <838vgiyh4q.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Richard Stallman , handa@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Wed, 23 May 2012 10:16:17 -0400 > > > Which other places use C pointers to buffer text and call functions > > that can allocate memory? > > IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text is > vulnerable to the problem. That's not true. As long as you access buffer text through character position, you are safe. The only situation where you are vulnerable is if you store a C pointer to buffer text, e.g., like this: char *text = BEGV_ADDR; or char *text = BYTE_POS_ADDR (current_buffer->pt); then invoke some function that can allocate or reallocate memory, and _then_ access buffer text through that pointer. If you find such a code anywhere, then that's a bug similar to this one. > If you really want to install your workaround on the emacs-24 branch, go > for it but let's try to find a real fix for the trunk. What kind of real fix are you looking for? I agree with Handa-san: being able to suppress relocation in select places is a good feature. Why shouldn't it be the fix in this case, and what better fix can we invent when we use an essentially externally maintained code (AFAIR, regex will at some point be re-sync'ed with gnulib) that cannot be expected to change its code radically so as not to access buffer text through C pointers? > >> >> I wonder: why do we use REL_ALLOC? > >> > AFAIK, we do that only on platforms that don't support mmap for > >> > allocating buffer text. > >> So, IIUC the only reason to use it is so that we can more often return > >> memory to the OS even for the non-mmap case? Is that because returning > >> memory can only be done via sbrk style memory management? > > I don't think this is only about _returning_ memory. It is first and > > foremost about not _asking_ for more memory when we can come up with > > it by reshuffling buffer text. > > So you're saying it's use for fragmentation reasons? Yes. > But on other platforms where we use mmap, we do suffer from this > fragmentation, and yet it doesn't seem to be a real source of problem. I don't know enough about mmap to answer that. I vaguely recollect that mmap avoids such fragmentation as an inherent feature, but I may be wrong. > That's why I think the only real reason is because memory can only be > returned via sbrk-style memory management (i.e. only free memory at the > end of the heap can be returned). Is that right? Yes, AFAIK. > I guess my question turns into "why do we use gmalloc.c instead of > a malloc library that uses mmap (or some other mechanism that lets it > return large free chunks to the OS)"? Use of gmalloc is a different issue. We were talking about ralloc.c. You could use one, but not the other. > AFAIK, Windows is pretty much the only system where we use gmalloc.c and > ralloc.c nowadays. My reading of configure is that we use it on more than just Windows (and MS-DOS). Basically, any platform that uses gmalloc.c (which is the default, turned off only for GNU/Linux and Darwin) also uses ralloc.c. > Does anyone remember why we don't use the system malloc under > Windows (and Cygwin)? I find it hard to believe that going through system malloc on MS-Windows will let us use buffers as large as 1.5 GB (on a 32-bit machine). To achieve this today, we reserve a 2GB contiguous chunk of address space at startup, and then commit and uncommit parts of it as needed (see w32heap.c). ralloc.c has an important part in this arrangement. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 17:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133779261732487 (code B ref 11519); Wed, 23 May 2012 17:04:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 17:03:37 +0000 Received: from localhost ([127.0.0.1]:40850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXEyG-0008Rw-Nd for submit@debbugs.gnu.org; Wed, 23 May 2012 13:03:36 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:38850) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXExv-0008RP-SM for 11519@debbugs.gnu.org; Wed, 23 May 2012 13:03:35 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4H00B00IPKU200@a-mtaout20.012.net.il> for 11519@debbugs.gnu.org; Wed, 23 May 2012 20:02:03 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4H00BPHJBDF0B0@a-mtaout20.012.net.il>; Wed, 23 May 2012 20:02:02 +0300 (IDT) Date: Wed, 23 May 2012 20:02:14 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <837gw2ygo9.fsf@gnu.org> References: <8762bn56ok.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: eliz@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Wed, 23 May 2012 11:27:16 -0400 > > We could suppress relocation all the time. I suspect that will increase the probability of out-of-memory conditions due to fragmentation, and system-wide memory pressure in general, on those platforms that do use ralloc.c today. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 17:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13377945192770 (code B ref 11519); Wed, 23 May 2012 17:36:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 17:35:19 +0000 Received: from localhost ([127.0.0.1]:40869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXFSx-0000id-1E for submit@debbugs.gnu.org; Wed, 23 May 2012 13:35:19 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:58195) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXFSu-0000iP-Gd for 11519@debbugs.gnu.org; Wed, 23 May 2012 13:35:18 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M4H00H00KN78600@a-mtaout21.012.net.il> for 11519@debbugs.gnu.org; Wed, 23 May 2012 20:34:19 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4H00HIPKT58I00@a-mtaout21.012.net.il>; Wed, 23 May 2012 20:34:19 +0300 (IDT) Date: Wed, 23 May 2012 20:34:30 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8362bmyf6h.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Richard Stallman , handa@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Wed, 23 May 2012 10:16:17 -0400 > > If you really want to install your workaround on the emacs-24 branch, go > for it Done (revision 108012 on the emacs-24 branch). From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 20:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133780370519057 (code B ref 11519); Wed, 23 May 2012 20:09:01 +0000 Received: (at 11519) by debbugs.gnu.org; 23 May 2012 20:08:25 +0000 Received: from localhost ([127.0.0.1]:41025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXHr6-0004xJ-FC for submit@debbugs.gnu.org; Wed, 23 May 2012 16:08:24 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:54290) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXHqm-0004wV-8F for 11519@debbugs.gnu.org; Wed, 23 May 2012 16:08:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCpYd/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0QAROIHAWrSo4/kEQDozOBWIMF X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="182045952" Received: from 76-10-150-29.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 May 2012 16:07:07 -0400 Received: by pastel.home (Postfix, from userid 20848) id 581D858C01; Wed, 23 May 2012 16:07:06 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> Date: Wed, 23 May 2012 16:07:05 -0400 In-Reply-To: <838vgiyh4q.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 May 2012 19:52:21 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > Which other places use C pointers to buffer text and call functions >> > that can allocate memory? >> IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text is >> vulnerable to the problem. > That's not true. As long as you access buffer text through character > position, you are safe. Right, some of those uses might be safe, indeed. Of course it's not only STRING_CHAR_AND_LENGTH but STRING_CHAR_ADVANCE as well, together with FETCH_* macros which use those, etc... Grepping for those macros shows they're used at *many* places, and I'd be amazed if re_search is the only place where we don't go through the BYTE_POS_ADDR rigmarole. Let's see ...hmmm... yup, set-buffer-multibyte is another example, find_charsets_in_text yet another, and I'm not even trying hard. Just grep for "STRING_CHAR_" and see for yourself. >> If you really want to install your workaround on the emacs-24 branch, go >> for it but let's try to find a real fix for the trunk. > What kind of real fix are you looking for? One that lets us write code without having to worry about such corner cases. E.g. changing STRING_CHAR_ADVANCE so it can't cause relocation. Not using ralloc.c any more would be another good option. Otherwise, changing our macros so they do the BYTE_POS_ADDR internally, discouraging the use of direct pointers into the buffer's content. > Why shouldn't it be the fix in this case, and what better fix can we > invent when we use an essentially externally maintained code (AFAIR, > regex will at some point be re-sync'ed with gnulib) that cannot be > expected to change its code radically so as not to access buffer text > through C pointers? To me, it's clearly a workaround. It's an OK workaround if/when we use a "blackbox" (i.e. externally maintained) regexp engine and keep using ralloc.c. But better would be to eliminate the problem altogether. >> But on other platforms where we use mmap, we do suffer from this >> fragmentation, and yet it doesn't seem to be a real source of problem. > I don't know enough about mmap to answer that. I vaguely recollect > that mmap avoids such fragmentation as an inherent feature, but I may > be wrong. No, fragmentation is a property of the address space, so without relocation you can't avoid it. >> I guess my question turns into "why do we use gmalloc.c instead of >> a malloc library that uses mmap (or some other mechanism that lets it >> return large free chunks to the OS)"? > Use of gmalloc is a different issue. We were talking about ralloc.c. > You could use one, but not the other. Well, still we use ralloc because we don't use mmap, so the question to me is: why don't we use mmap (either via a malloc that does, or directly via USE_MMAP_FOR_BUFFERS) and get rid of ralloc.c? >> AFAIK, Windows is pretty much the only system where we use gmalloc.c and >> ralloc.c nowadays. > My reading of configure is that we use it on more than just Windows > (and MS-DOS). Basically, any platform that uses gmalloc.c (which is > the default, turned off only for GNU/Linux and Darwin) also uses > ralloc.c. To me "all minus GNU/Linux, Mac OS X, and Cygwin (which apparently uses gmalloc but not ralloc)" is pretty close to "just Windows" nowadays. >> Does anyone remember why we don't use the system malloc under >> Windows (and Cygwin)? > I find it hard to believe that going through system malloc on > MS-Windows will let us use buffers as large as 1.5 GB (on a 32-bit > machine). To achieve this today, we reserve a 2GB contiguous chunk of > address space at startup, and then commit and uncommit parts of it as > needed (see w32heap.c). ralloc.c has an important part in this > arrangement. You mean that Windows's system malloc library has a memory that's too fragmented to be able to allocate a single 1.5G chunk? Why? [ I know next to nothing about the w32 API and plead guilty of POSIX-only thinking, so please bear with me. ] Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 May 2012 16:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13378766267300 (code B ref 11519); Thu, 24 May 2012 16:24:02 +0000 Received: (at 11519) by debbugs.gnu.org; 24 May 2012 16:23:46 +0000 Received: from localhost ([127.0.0.1]:42203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXapE-0001tg-M2 for submit@debbugs.gnu.org; Thu, 24 May 2012 12:23:46 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:44823) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXapA-0001tI-KQ for 11519@debbugs.gnu.org; Thu, 24 May 2012 12:23:42 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4J00300BWQSE00@a-mtaout20.012.net.il> for 11519@debbugs.gnu.org; Thu, 24 May 2012 19:22:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4J002I5C5JWPH0@a-mtaout20.012.net.il>; Thu, 24 May 2012 19:22:32 +0300 (IDT) Date: Thu, 24 May 2012 19:22:46 +0300 From: Eli Zaretskii In-reply-to: Message-id: <83wr41wnu1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: rms@gnu.org, handa@gnu.org, schwab@linux-m68k.org, lekktu@gm= ail.com, 11519@debbugs.gnu.org > Date: Wed, 23 May 2012 16:07:05 -0400 >=20 > >> > Which other places use C pointers to buffer text and call func= tions > >> > that can allocate memory? > >> IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text i= s > >> vulnerable to the problem. > > That's not true. As long as you access buffer text through chara= cter > > position, you are safe. >=20 > Right, some of those uses might be safe, indeed. Of course it's no= t > only STRING_CHAR_AND_LENGTH but STRING_CHAR_ADVANCE as well, togeth= er > with FETCH_* macros which use those, etc... No, FETCH_* macros are safe, because they accept buffer positions, fetch only one character at a time, and call STRING_CHAR_* _after_ they access the buffer. > Grepping for those macros shows they're used at *many* places, and = I'd > be amazed if re_search is the only place where we don't go through = the > BYTE_POS_ADDR rigmarole. >=20 > Let's see ...hmmm... yup, set-buffer-multibyte is another example, > find_charsets_in_text yet another, and I'm not even trying hard. > Just grep for "STRING_CHAR_" and see for yourself. I didn't mean STRING_CHAR_*. I agree that they should be fixed not t= o have such unexpected side effect. They should be read-only operation= s. As a temporary band-aid for Emacs 24.1, I suggest the change below. What I meant is the code besides STRING_CHAR_* macros. I don't think you will find code that manipulates C pointers to buffer text and calls functions that can allocate memory. > >> But on other platforms where we use mmap, we do suffer from this > >> fragmentation, and yet it doesn't seem to be a real source of pr= oblem. > > I don't know enough about mmap to answer that. I vaguely recolle= ct > > that mmap avoids such fragmentation as an inherent feature, but I= may > > be wrong. >=20 > No, fragmentation is a property of the address space, so without > relocation you can't avoid it. I asked Gerd M=F6llmann, who wrote the mmap-based buffer allocation code, about this. That code originally resided on ralloc.c and was meant to replace the sbrk-based implementation. So I would expect that the issue of relocation was considered back then, and I hope Ger= d will remember why the mmap-based code was considered good enough to replace ralloc.c. > > I find it hard to believe that going through system malloc on > > MS-Windows will let us use buffers as large as 1.5 GB (on a 32-bi= t > > machine). To achieve this today, we reserve a 2GB contiguous chu= nk of > > address space at startup, and then commit and uncommit parts of i= t as > > needed (see w32heap.c). ralloc.c has an important part in this > > arrangement. >=20 > You mean that Windows's system malloc library has a memory that's t= oo > fragmented to be able to allocate a single 1.5G chunk? Why? This has nothing to do with Windows APIs, so you are well equipped to reason about this ;-) You said "malloc", so I took an issue with the MS C runtime implementation of malloc. Since all the other implementations suffer =66rom fragmentation, there's no reason to believe that the MS implementation avoids that danger. A general-purpose function that cannot move buffers behind the scenes cannot possibly avoid that. Doing better was the original reason for writing ralloc.c. If you meant to bypass malloc and use the Windows memory-allocation APIs, such as VirtualAlloc, directly, then that's what we already do in w32heap.c, which implements an emulation of sbrk that is good enough for Emacs. The fact that gmalloc and ralloc are used on top o= f that are simply to avoid reinventing the wheel. We could easily turn off buffer relocation in ralloc.c for good, by fixing the value of use_relocatable_buffers at zero. But I'm worried that this would cause Emacs on Windows run out of memory (or act as i= f it were) faster. For example, in an Emacs session that runs for 2 weeks and has a 200MB working set, I just visited a 1.3GB file, went to its middle and typed "C-u 30000 d" to insert 30K characters. Emac= s had no problems enlarging the buffer, although it has only 1.9GB of reserved memory space on that machine, so if it needed to allocate another 1.3GB+30KB buffer (due to fragmentation, which is a certainty after such a long time), it would have failed, I presume. Yet another alternative is to emulate mmap on Windows using the equivalent Windows API. But that requires a research comparing mmap features we need and use on Posix platforms with the features offered by Windows, to make sure this is at all feasible. Such a research would need to be done by someone who knows enough about mmap and is willing to do the job. Do we have such a person on board? And then there's the implementation and testing. Doesn't sound like an efficient use of our time and energy. Are there other alternatives? Here's the band-aid I propose for emacs-24, to make the STRING_CHAR_* macros safe: =3D=3D=3D modified file 'src/charset.c' --- src/charset.c=092012-01-19 07:21:25 +0000 +++ src/charset.c=092012-05-24 16:14:05 +0000 @@ -1641,6 +1641,12 @@ maybe_unify_char (int c, Lisp_Object val return c; =20 CHECK_CHARSET_GET_CHARSET (val, charset); +#ifdef REL_ALLOC + /* The call to load_charset below can allocate memory, whcih screw= s + callers of this function through STRING_CHAR_* macros that hold= C + pointers to buffer text, if REL_ALLOC is used. */ + r_alloc_inhibit_buffer_relocation (1); +#endif load_charset (charset, 1); if (! inhibit_load_charset_map) { @@ -1656,6 +1662,9 @@ maybe_unify_char (int c, Lisp_Object val if (unified > 0) =09c =3D unified; } +#ifdef REL_ALLOC + r_alloc_inhibit_buffer_relocation (0); +#endif return c; } =20 =3D=3D=3D modified file 'src/ralloc.c' --- src/ralloc.c=092012-05-23 17:32:28 +0000 +++ src/ralloc.c=092012-05-24 16:16:14 +0000 @@ -1204,7 +1204,12 @@ r_alloc_reset_variable (POINTER *old, PO void r_alloc_inhibit_buffer_relocation (int inhibit) { - use_relocatable_buffers =3D !inhibit; + if (use_relocatable_buffers < 0) + use_relocatable_buffers =3D 0; + if (inhibit) + use_relocatable_buffers++; + else if (use_relocatable_buffers > 0) + use_relocatable_buffers--; } =20 =0C From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 May 2012 02:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133817138522845 (code B ref 11519); Mon, 28 May 2012 02:17:01 +0000 Received: (at 11519) by debbugs.gnu.org; 28 May 2012 02:16:25 +0000 Received: from localhost ([127.0.0.1]:45952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYpVQ-0005wQ-ID for submit@debbugs.gnu.org; Sun, 27 May 2012 22:16:24 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:9086) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYpVN-0005wC-TM for 11519@debbugs.gnu.org; Sun, 27 May 2012 22:16:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAG6Zu09MCpYd/2dsb2JhbABEr1qEN4EIghUBAQQBViMFCws0EhQYDRABE4gcBboJkEQDozOBWIMFgToa X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="183050477" Received: from 76-10-150-29.dsl.teksavvy.com (HELO ceviche.home) ([76.10.150.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 May 2012 22:15:00 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 2A6FF660E0; Sun, 27 May 2012 22:15:00 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> Date: Sun, 27 May 2012 22:15:00 -0400 In-Reply-To: <83wr41wnu1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 24 May 2012 19:22:46 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I didn't mean STRING_CHAR_*. I agree that they should be fixed not to > have such unexpected side effect. They should be read-only operations. > As a temporary band-aid for Emacs 24.1, I suggest the change below. Looks fine (should make the regex.c patch unnecessary). > You said "malloc", so I took an issue with the MS C runtime > implementation of malloc. Since all the other implementations suffer > from fragmentation, there's no reason to believe that the MS > implementation avoids that danger. The problem is inherent to the malloc API, pretty much, yes. > We could easily turn off buffer relocation in ralloc.c for good, by > fixing the value of use_relocatable_buffers at zero. But I'm worried > that this would cause Emacs on Windows run out of memory (or act as if > it were) faster. AFAIK, Emacs under GNU/Linux and Mac OS X uses non-relocatable buffers, and they don't seem to suffer more from fragmentation problems than Emacs under Windows. But yes, unless we use an mmap-style allocation, it would use more actual memory. > For example, in an Emacs session that runs for 2 > weeks and has a 200MB working set, I just visited a 1.3GB file, went > to its middle and typed "C-u 30000 d" to insert 30K characters. Emacs For sure editing such large file in a 32bit address space might prove problematic without relocation, (and even with buffer relocation, some non-buffer allocation might end up fragmenting the address space too much) but luckily few people do that (you need to compile with --wide-int to be able to do that). > Yet another alternative is to emulate mmap on Windows using the > equivalent Windows API. But that requires a research comparing mmap > features we need and use on Posix platforms with the features offered > by Windows, to make sure this is at all feasible. That would be nice. > Such a research > would need to be done by someone who knows enough about mmap and is > willing to do the job. Do we have such a person on board? I don't volunteer. Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 May 2012 16:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13382241109064 (code B ref 11519); Mon, 28 May 2012 16:56:01 +0000 Received: (at 11519) by debbugs.gnu.org; 28 May 2012 16:55:10 +0000 Received: from localhost ([127.0.0.1]:46849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ3Dp-0002M8-Uv for submit@debbugs.gnu.org; Mon, 28 May 2012 12:55:10 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:51644) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ3Dl-0002Lb-Qu for 11519@debbugs.gnu.org; Mon, 28 May 2012 12:55:07 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4Q00A00S7H9X00@a-mtaout20.012.net.il> for 11519@debbugs.gnu.org; Mon, 28 May 2012 19:53:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4Q009F3S9GL5C0@a-mtaout20.012.net.il>; Mon, 28 May 2012 19:53:40 +0300 (IDT) Date: Mon, 28 May 2012 19:53:44 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83k3zw1c2v.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: rms@gnu.org, handa@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Sun, 27 May 2012 22:15:00 -0400 > > > I didn't mean STRING_CHAR_*. I agree that they should be fixed not to > > have such unexpected side effect. They should be read-only operations. > > As a temporary band-aid for Emacs 24.1, I suggest the change below. > > Looks fine Installed as revision 108020 on the emacs-24 branch. > (should make the regex.c patch unnecessary). I wouldn't recommend removing the calls to r_alloc_inhibit_buffer_relocation around calls to regex, as that is an external function we don't control. But if you feel strongly about that, I will remove them. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 May 2012 19:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133823434227967 (code B ref 11519); Mon, 28 May 2012 19:46:02 +0000 Received: (at 11519) by debbugs.gnu.org; 28 May 2012 19:45:42 +0000 Received: from localhost ([127.0.0.1]:47039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ5sr-0007H2-VV for submit@debbugs.gnu.org; Mon, 28 May 2012 15:45:42 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:41688) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ5sq-0007Gw-Ex for 11519@debbugs.gnu.org; Mon, 28 May 2012 15:45:41 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q4SJiKr8008998; Mon, 28 May 2012 15:44:20 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 5A16CB4191; Mon, 28 May 2012 15:44:18 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> Date: Mon, 28 May 2012 15:44:18 -0400 In-Reply-To: <83k3zw1c2v.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 May 2012 19:53:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4235=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4235> : streams <761731> : uri <1120542> X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) >> (should make the regex.c patch unnecessary). > I wouldn't recommend removing the calls to > r_alloc_inhibit_buffer_relocation around calls to regex, as that is an > external function we don't control. But if you feel strongly about > that, I will remove them. I don't feel strongly about that. But this code is all ours, it's not an external function (it used to be half-external, and then I hacked on it half-extensively, after which the new version was sync'd back from Emacs to gnulib, after which the gnulib side dropped it, and AFAIK Emacs is the last remaining development line of this code, except maybe for XEmacs's version). Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 May 2012 20:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13382381354201 (code B ref 11519); Mon, 28 May 2012 20:49:02 +0000 Received: (at 11519) by debbugs.gnu.org; 28 May 2012 20:48:55 +0000 Received: from localhost ([127.0.0.1]:47079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ6rk-00015K-4b for submit@debbugs.gnu.org; Mon, 28 May 2012 16:48:55 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:44814) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ6ri-000156-Jd for 11519@debbugs.gnu.org; Mon, 28 May 2012 16:48:35 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4R00C00310IO00@a-mtaout20.012.net.il> for 11519@debbugs.gnu.org; Mon, 28 May 2012 23:47:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4R00BBS32KH1C0@a-mtaout20.012.net.il>; Mon, 28 May 2012 23:47:08 +0300 (IDT) Date: Mon, 28 May 2012 23:47:13 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83bol8119q.fsf@gnu.org> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: rms@gnu.org, handa@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, > 11519@debbugs.gnu.org > Date: Mon, 28 May 2012 15:44:18 -0400 > > > I wouldn't recommend removing the calls to > > r_alloc_inhibit_buffer_relocation around calls to regex, as that is an > > external function we don't control. But if you feel strongly about > > that, I will remove them. > > I don't feel strongly about that. But this code is all ours, it's not > an external function (it used to be half-external, and then I hacked on > it half-extensively, after which the new version was sync'd back from > Emacs to gnulib, after which the gnulib side dropped it, and AFAIK Emacs > is the last remaining development line of this code, except maybe for > XEmacs's version). If you are confident that regex.c doesn't call malloc in any other place, and that chances for it to do so in the future are low enough, then I'm okay with removing the calls to r_alloc_inhibit_buffer_relocation. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 May 2012 01:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133825468331452 (code B ref 11519); Tue, 29 May 2012 01:25:01 +0000 Received: (at 11519) by debbugs.gnu.org; 29 May 2012 01:24:43 +0000 Received: from localhost ([127.0.0.1]:47379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZBAx-0008BF-0A for submit@debbugs.gnu.org; Mon, 28 May 2012 21:24:43 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:34908) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZBAu-0008B2-T4 for 11519@debbugs.gnu.org; Mon, 28 May 2012 21:24:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCpYd/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="183354531" Received: from 76-10-150-29.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 May 2012 21:23:14 -0400 Received: by pastel.home (Postfix, from userid 20848) id E7981599A3; Mon, 28 May 2012 21:23:13 -0400 (EDT) From: Stefan Monnier Message-ID: References: <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> <83bol8119q.fsf@gnu.org> Date: Mon, 28 May 2012 21:23:13 -0400 In-Reply-To: <83bol8119q.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 May 2012 23:47:13 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > If you are confident that regex.c doesn't call malloc in any other > place, and that chances for it to do so in the future are low enough, I'm pretty confident, yes. Stefan From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 May 2012 16:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: handa@gnu.org, schwab@linux-m68k.org, rms@gnu.org, 11519@debbugs.gnu.org, lekktu@gmail.com Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133830742931568 (code B ref 11519); Tue, 29 May 2012 16:04:01 +0000 Received: (at 11519) by debbugs.gnu.org; 29 May 2012 16:03:49 +0000 Received: from localhost ([127.0.0.1]:48590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZOtg-0008D7-UM for submit@debbugs.gnu.org; Tue, 29 May 2012 12:03:49 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:56599) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZOtd-0008Cs-Hj for 11519@debbugs.gnu.org; Tue, 29 May 2012 12:03:46 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M4S00600KHCN800@a-mtaout21.012.net.il> for 11519@debbugs.gnu.org; Tue, 29 May 2012 19:02:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S006VEKJPCG70@a-mtaout21.012.net.il>; Tue, 29 May 2012 19:02:14 +0300 (IDT) Date: Tue, 29 May 2012 19:02:20 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8362bf2cxf.fsf@gnu.org> References: <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> <83bol8119q.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: rms@gnu.org, handa@gnu.org, schwab@linux-m68k.org, lekktu@gmail.com, 11519@debbugs.gnu.org > Date: Mon, 28 May 2012 21:23:13 -0400 > > > If you are confident that regex.c doesn't call malloc in any other > > place, and that chances for it to do so in the future are low enough, > > I'm pretty confident, yes. Removed in revision 108021 on the emacs-24 branch. From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Jun 2012 20:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133867003818638 (code B ref 11519); Sat, 02 Jun 2012 20:48:02 +0000 Received: (at 11519) by debbugs.gnu.org; 2 Jun 2012 20:47:18 +0000 Received: from localhost ([127.0.0.1]:54959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SavEE-0004qZ-4g for submit@debbugs.gnu.org; Sat, 02 Jun 2012 16:47:18 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:59993) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SavEA-0004qM-Ib for 11519@debbugs.gnu.org; Sat, 02 Jun 2012 16:47:15 -0400 Received: by pbcwy7 with SMTP id wy7so4049105pbc.3 for <11519@debbugs.gnu.org>; Sat, 02 Jun 2012 13:45:19 -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:content-type:content-transfer-encoding; bh=q6cPL/rJ4TLQFEGs+YQ9xoVYnY5k/4Fkr+jQxI3lkfI=; b=NWnO4eEfzSogt2gSzO9CMDIZ9zk5RmGdD4SBbGnvaX5Wbe4HUtp5JAiQk12PwdTG3l phOLd+PZ39VNlV9OGLxJPCbMSViyAnXST7k/v5G+uhsJHhTKjTVJD1BTC+QAO4ECyH8n hCwLkiWx1BtDMgTSaOb0Z3AYDIEGpmYWzgebPjhn/L2UvYC4yO4nN7oRSlMj/WwEn1dt qRYJv+URkKNjoj3BZ7SHImKvrJKJTNGihON3vCqjVRHFW3yrZP7e+oOrrBXgWnyBwak8 aWh240WTXhy0jdbWbjBU29LVPz9er/13gK18/E3dFr26HcJB5LyKJCVIGKN8HxGJb2/i FbFA== Received: by 10.68.203.35 with SMTP id kn3mr22678596pbc.163.1338669919275; Sat, 02 Jun 2012 13:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.164.7 with HTTP; Sat, 2 Jun 2012 13:44:39 -0700 (PDT) In-Reply-To: <8362bf2cxf.fsf@gnu.org> References: <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> <83bol8119q.fsf@gnu.org> <8362bf2cxf.fsf@gnu.org> From: Juanma Barranquero Date: Sat, 2 Jun 2012 22:44:39 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > Removed in revision 108021 on the emacs-24 branch. This bug fix hasn't yet been ported back to the trunk, has it? =C2=A0 =C2=A0 Juanma From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Jun 2012 04:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juanma Barranquero Cc: 11519@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13386972471429 (code B ref 11519); Sun, 03 Jun 2012 04:21:02 +0000 Received: (at 11519) by debbugs.gnu.org; 3 Jun 2012 04:20:47 +0000 Received: from localhost ([127.0.0.1]:55165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sb2J4-0000N0-VT for submit@debbugs.gnu.org; Sun, 03 Jun 2012 00:20:47 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:36994) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sb2Ik-0000MS-Q9 for 11519@debbugs.gnu.org; Sun, 03 Jun 2012 00:20:45 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M5000K00X6ZKB00@a-mtaout22.012.net.il> for 11519@debbugs.gnu.org; Sun, 03 Jun 2012 07:18:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M5000JZOXAUXOC0@a-mtaout22.012.net.il>; Sun, 03 Jun 2012 07:18:30 +0300 (IDT) Date: Sun, 03 Jun 2012 07:18:35 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834nqtc9k4.fsf@gnu.org> References: <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> <83bol8119q.fsf@gnu.org> <8362bf2cxf.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Juanma Barranquero > Date: Sat, 2 Jun 2012 22:44:39 +0200 > Cc: 11519@debbugs.gnu.org > > > Removed in revision 108021 on the emacs-24 branch. > > This bug fix hasn't yet been ported back to the trunk, has it? ?? Of course, it was. The function maybe_unify_char inhibits relocation of buffer text. Why, did you have the problem again? From unknown Mon Sep 08 20:06:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Resent-From: Glenn Morris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2013 08:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Juanma Barranquero , 11519@debbugs.gnu.org Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.13882200944315 (code B ref 11519); Sat, 28 Dec 2013 08:42:02 +0000 Received: (at 11519) by debbugs.gnu.org; 28 Dec 2013 08:41:34 +0000 Received: from localhost ([127.0.0.1]:47786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwpSg-00017X-96 for submit@debbugs.gnu.org; Sat, 28 Dec 2013 03:41:34 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:52259) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwpSf-00017R-7k for 11519@debbugs.gnu.org; Sat, 28 Dec 2013 03:41:33 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1VwpSe-0005Lc-AE; Sat, 28 Dec 2013 03:41:32 -0500 From: Glenn Morris References: <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> <83bol8119q.fsf@gnu.org> <8362bf2cxf.fsf@gnu.org> <834nqtc9k4.fsf@gnu.org> X-Spook: Glock asset anarchy Cocaine Gazprom SWAT monarchist lynch X-Ran: s!gvOVM%?f{LKyaWqh6']Ag3%v}\L6ydEG.A*u'x$-6LApO)$Q{|Sx{ec#[[18#Uo8xs)( X-Hue: yellow X-Attribution: GM Date: Sat, 28 Dec 2013 03:41:32 -0500 In-Reply-To: <834nqtc9k4.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 Jun 2012 07:18:35 +0300") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.6 (-----) Is this report still relevant? From unknown Mon Sep 08 20:06:12 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Juanma Barranquero Subject: bug#11519: closed (Re: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping) Message-ID: References: <83sitd2tn9.fsf@gnu.org> X-Gnu-PR-Message: they-closed 11519 X-Gnu-PR-Package: emacs Reply-To: 11519@debbugs.gnu.org Date: Sat, 28 Dec 2013 09:49:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1388224143-16602-1" This is a multi-part message in MIME format... ------------=_1388224143-16602-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #11519: "Wrong type argument: characterp" building custom-deps while boostr= apping which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 11519@debbugs.gnu.org. --=20 11519: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11519 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1388224143-16602-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 11519-done) by debbugs.gnu.org; 28 Dec 2013 09:48:49 +0000 Received: from localhost ([127.0.0.1]:47838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwqVk-0004JF-VU for submit@debbugs.gnu.org; Sat, 28 Dec 2013 04:48:49 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:46837) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwqVg-0004J2-NK for 11519-done@debbugs.gnu.org; Sat, 28 Dec 2013 04:48:46 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MYI00C00GFKG200@a-mtaout21.012.net.il> for 11519-done@debbugs.gnu.org; Sat, 28 Dec 2013 11:48:43 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MYI00CAXGL6DF20@a-mtaout21.012.net.il>; Sat, 28 Dec 2013 11:48:43 +0200 (IST) Date: Sat, 28 Dec 2013 11:48:26 +0200 From: Eli Zaretskii Subject: Re: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping In-reply-to: X-012-Sender: halo1@inter.net.il To: Glenn Morris Message-id: <83sitd2tn9.fsf@gnu.org> References: <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> <838vgiyh4q.fsf@gnu.org> <83wr41wnu1.fsf@gnu.org> <83k3zw1c2v.fsf@gnu.org> <83bol8119q.fsf@gnu.org> <8362bf2cxf.fsf@gnu.org> <834nqtc9k4.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 11519-done Cc: lekktu@gmail.com, 11519-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Glenn Morris > Cc: Juanma Barranquero , 11519@debbugs.gnu.org > Date: Sat, 28 Dec 2013 03:41:32 -0500 > > > Is this report still relevant? No. Closing. ------------=_1388224143-16602-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 19 May 2012 16:11:32 +0000 Received: from localhost ([127.0.0.1]:34582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVmFf-0006t2-JM for submit@debbugs.gnu.org; Sat, 19 May 2012 12:11:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42941) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SVmFd-0006sn-1b for submit@debbugs.gnu.org; Sat, 19 May 2012 12:11:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVmF5-0007gK-7u for submit@debbugs.gnu.org; Sat, 19 May 2012 12:10:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:32826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVmF5-0007gG-26 for submit@debbugs.gnu.org; Sat, 19 May 2012 12:10:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVmF3-0003mj-BA for bug-gnu-emacs@gnu.org; Sat, 19 May 2012 12:10:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVmF1-0007fn-GN for bug-gnu-emacs@gnu.org; Sat, 19 May 2012 12:10:52 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:44991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVmF1-0007eQ-7p for bug-gnu-emacs@gnu.org; Sat, 19 May 2012 12:10:51 -0400 Received: by pbbrp2 with SMTP id rp2so5562588pbb.0 for ; Sat, 19 May 2012 09:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=Xj4mSYDdeAkaj3n9jMpWi7Jvx4tGjDYwdrAxNkm53sE=; b=uElw2pLxyt88vO2AogVUnGtjOu6UOtXZX4UR+lQSGCo/J6vt8j9T9DSkjAbqaSm0/j lBhG4oiS7Kbh72z5TSMVnLuQBVQthwBtBxhORiJNbwrgX/7fNBRVyhAPIgHV6Mnv/Cre uwFZzLHSkvJmcc1ylPJtJhkI2jPqU5GkZKmNGvNA2cxL7hqSOI4XuWdWweOXajS5L2dM ojw2HIiWN4AMrP46IVhhgO5kPkZ12PmHXNCdK66AETbQwB86LsXIK8UceK5W/atQfBSa xUvsEEklXdBu7Y9k9KHnTVg32mbYq0BbKXc6wTrsoMO2pinpulBz9XX3nvauy/g9ZhOU 1YyA== Received: by 10.68.190.131 with SMTP id gq3mr51445494pbc.17.1337443848271; Sat, 19 May 2012 09:10:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.19.8 with HTTP; Sat, 19 May 2012 09:10:07 -0700 (PDT) From: Juanma Barranquero Date: Sat, 19 May 2012 18:10:07 +0200 Message-ID: Subject: "Wrong type argument: characterp" building custom-deps while boostrapping To: Bug-Gnu-Emacs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Package: emacs Version: 24.1.50 With current trunk (revno:108308) bootstrapping on Windows throws an error while building custom-deps: make -w cus-load.el-CMD make[2]: Entering directory `C:/emacs/debug/lisp' echo ;;; cus-load.el --- automatically extracted custom dependencies> cus-load.el-CMD echo ;;>> cus-load.el-CMD echo ;;; Code:>> cus-load.el-CMD echo.=0C>> cus-load.el-CMD echo ;; Local Variables:>> cus-load.el-CMD echo ;; version-control: never>> cus-load.el-CMD echo ;; no-byte-compile: t>> cus-load.el-CMD echo ;; no-update-autoloads: t>> cus-load.el-CMD echo ;; End:>> cus-load.el-CMD make[2]: Leaving directory `C:/emacs/debug/lisp' mv cus-load.el-CMD C:/emacs/debug/lisp/cus-load.el Directories: calc calendar emacs-lisp emulation erc eshell gnus international language mail mh-e net nxml org play progmodes textmodes url vc cedet ce "../src/oo/i386/emacs.exe" -batch --no-site-file --no-site-lisp -l cus-dep --eval "(setq find-file-hook nil)" \ -f custom-make-dependencies C:/Devel/emacs/repo/debug/lisp calc calendar emacs-lisp emulation erc eshell gnus international language Directory C:/emacs/debug/lisp Directory calc Directory calendar Directory emacs-lisp Directory emulation Directory erc Directory eshell Directory gnus Directory international Directory language Wrong type argument: characterp, 4195283 make[1]: [custom-deps] Error -1 (ignored) rm "../src/oo/i386/emacs.exe" After bootstraping, cd lisp make custom-deps works as expected. The error appeared somewhere in the past ten days or so (I have a bootstrap log from 2012-05-08 which does not show the problem). =C2=A0 =C2=A0 Juanma ------------=_1388224143-16602-1--