From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#15405: 24.3; #[] freezes emacs Date: Wed, 25 Sep 2013 11:22:34 -0400 Message-ID: References: <8361tynp73.fsf@gnu.org> <834n9inoa0.fsf@gnu.org> <871u4mcf2h.fsf@rosalinde.fritz.box> <831u4mnlit.fsf@gnu.org> <83txhilymg.fsf@gnu.org> <83ob7pmh28.fsf@gnu.org> <523CF65A.7010607@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01493c329582e004e736d21e X-Trace: ger.gmane.org 1380122595 3457 80.91.229.3 (25 Sep 2013 15:23:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Sep 2013 15:23:15 +0000 (UTC) Cc: Dmitry Antipov , 15405@debbugs.gnu.org, Leo Liu , stephen.berman@gmx.net To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 25 17:23:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VOqvu-0000W1-Jh for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Sep 2013 17:23:18 +0200 Original-Received: from localhost ([::1]:53305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOqvu-00048J-4C for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Sep 2013 11:23:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOqvl-00047K-4y for bug-gnu-emacs@gnu.org; Wed, 25 Sep 2013 11:23:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOqvf-0005Ba-4G for bug-gnu-emacs@gnu.org; Wed, 25 Sep 2013 11:23:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOqvf-0005BV-0f for bug-gnu-emacs@gnu.org; Wed, 25 Sep 2013 11:23:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VOqve-0002cG-9F for bug-gnu-emacs@gnu.org; Wed, 25 Sep 2013 11:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Sep 2013 15:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15405 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15405-submit@debbugs.gnu.org id=B15405.13801225589998 (code B ref 15405); Wed, 25 Sep 2013 15:23:02 +0000 Original-Received: (at 15405) by debbugs.gnu.org; 25 Sep 2013 15:22:38 +0000 Original-Received: from localhost ([127.0.0.1]:35406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VOqvF-0002bA-RV for submit@debbugs.gnu.org; Wed, 25 Sep 2013 11:22:38 -0400 Original-Received: from mail-wg0-f43.google.com ([74.125.82.43]:35712) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VOqvD-0002b1-2q for 15405@debbugs.gnu.org; Wed, 25 Sep 2013 11:22:35 -0400 Original-Received: by mail-wg0-f43.google.com with SMTP id z12so6403961wgg.22 for <15405@debbugs.gnu.org>; Wed, 25 Sep 2013 08:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i6/iAcL0ynhOj37O+yK8N4qcuTAQXEqTbZns/bvps5M=; b=hxqGP4Y/nEboeTo+mVc6t7cBiGko/gjVFeaakNoHgyZPhLpkG8y/b5FkzJCmqKDTX1 nGJmgysJhopp1GT67C02R+2U2NXUIRJ6EF4Dw0t9ri6HiPt+BzZ4fg5XWK88WERyltQS g2tHWXhY6kz369Hxcr7nLT2Ic01FKqJVmgvNwfl7YMTspZGvWoO0uXg/c/lXMvCyqjF3 s8efmWnxu96b8zw4rhUOlB7EtWxWRI8O/fNO+jWIAipfBpqo3DktvdmSuEi4XLeYcoBG VJf8GkFPsalvB9sKFV16ONwLjLREVzohnHSzxjD5YxWjd9aV4A007492g/twxrkm4BlH lhSg== X-Received: by 10.194.241.228 with SMTP id wl4mr27921189wjc.2.1380122554104; Wed, 25 Sep 2013 08:22:34 -0700 (PDT) Original-Received: by 10.194.17.72 with HTTP; Wed, 25 Sep 2013 08:22:34 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78733 Archived-At: --089e01493c329582e004e736d21e Content-Type: text/plain; charset=ISO-8859-1 >From the code, I thought I could make the following change and have zero vectors participate in the vector_free_lists. --- a/src/alloc.c +++ b/src/alloc.c @@ -2626,7 +2626,7 @@ verify (VECTOR_BLOCK_SIZE <= (1 << PSEUDOVECTOR_SIZE_BITS)); /* Size of the minimal vector allocated from block. */ -#define VBLOCK_BYTES_MIN vroundup_ct (header_size + sizeof (Lisp_Object)) +#define VBLOCK_BYTES_MIN vroundup_ct (header_size) /* Size of the largest vector allocated from block. */ After debugging the subsequent core dumping, I found it doesn't work because Lisp_Vector is defined by: struct Lisp_Vector { struct vectorlike_header header; union { /* ...but sometimes there is also a pointer internally used in vector allocation code. Usually you don't want to touch this. */ struct Lisp_Vector *next; /* We can't use FLEXIBLE_ARRAY_MEMBER here. */ Lisp_Object contents[1]; } u; }; Without any special casing of zero vectors, the allocator calls SETUP_ON_FREE_LIST for a zero vector and sets v->u.next. But for a zero vector the allocator only allows enough memory for the header, so setting the next pointer corrupts other memory. Of course when a non zero vector is taken from the free list, the next pointer is no longer needed and can be overridden by the contents. Clever use of space. Which of these solutions would be most palatable? - Allocate zero vectors as "large_vectors", but with appropriate renaming of "large". - Allocate separately as a MEM_TYPE_VECTORLIKE, maintain a list of zero_vectors for GC - Smuggle zero vectors on the vector_free_lists with same allocation size as a 1-vector --089e01493c329582e004e736d21e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From the code, I thought I could make the following change= and have
zero vectors participate in the vector_free_lists.

--- = a/src/alloc.c
+++ b/src/alloc.c
@@ -2626,7 +2626,7 @@ verify (VECTOR_= BLOCK_SIZE <=3D (1 << PSEUDOVECTOR_SIZE_BITS));
=A0
=A0/* Size of the minimal vector allocated from block.=A0 */
=A0<= br>-#define VBLOCK_BYTES_MIN vroundup_ct (header_size + sizeof (Lisp_Object= ))
+#define VBLOCK_BYTES_MIN vroundup_ct (header_size)
=A0
=A0/* S= ize of the largest vector allocated from block.=A0 */

After debugging the subsequent core dumping, I found it doesn't wor= k
because Lisp_Vector is defined by:

struct Lisp_Vector
=A0 {<= br>=A0=A0=A0 struct vectorlike_header header;
=A0=A0=A0 union {
=A0= =A0=A0=A0=A0 /* ...but sometimes there is also a pointer internally used in=
=A0=A0=A0 =A0vector allocation code.=A0 Usually you don't want to touch= this.=A0 */
=A0=A0=A0=A0=A0 struct Lisp_Vector *next;
=A0=A0=A0=A0= =A0
=A0=A0=A0=A0=A0 /* We can't use FLEXIBLE_ARRAY_MEMBER here.=A0 = */
=A0=A0=A0=A0=A0 Lisp_Object contents[1];
=A0=A0=A0 } u;
=A0 };

Without any special casing of zero vectors, the allocator cal= ls
SETUP_ON_FREE_LIST for a zero vector and sets v->u.next. But for a=
zero vector the allocator only allows enough memory for the header, so<= br> setting the next pointer corrupts other memory.

Of course when a non= zero vector is taken from the free list, the next
pointer is no longer = needed and can be overridden by the contents.
Clever use of space.

Which of these solutions would be most palatable?
=A0 - Allocate zer= o vectors as "large_vectors", but with appropriate
=A0=A0=A0 r= enaming of "large".
=A0 - Allocate separately as a MEM_TYPE_VE= CTORLIKE, maintain a list of
=A0=A0=A0 zero_vectors for GC
=A0 - Smuggle zero vectors on the vector_f= ree_lists with same allocation
=A0=A0=A0 size as a 1-vector

--089e01493c329582e004e736d21e--