From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: buffer.c/buffer.h: How to add new buffer-local variables?
Date: Mon, 08 Apr 2019 12:37:57 +0300
Message-ID: <3C6817C0-1CDB-4F83-805E-BF6B93C77F44@gnu.org>
References: <m2r2ac9b5m.wl%esq@lawlist.com>
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="104556"; mail-complaints-to="usenet@blaine.gmane.org"
User-Agent: K-9 Mail for Android
Cc: acm@muc.de, dancol@dancol.org, schwab@linux-m68k.org,
	monnier@iro.umontreal.ca
To: emacs-devel@gnu.org, Keith David Bershatsky <esq@lawlist.com>,
	Paul Eggert <eggert@cs.ucla.edu>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 08 11:38:24 2019
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1hDQjO-000R0s-6R
	for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 11:38:22 +0200
Original-Received: from localhost ([127.0.0.1]:50139 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1hDQjN-0000xj-3I
	for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 05:38:21 -0400
Original-Received: from eggs.gnu.org ([209.51.188.92]:44050)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1hDQj9-0000tV-7C
	for emacs-devel@gnu.org; Mon, 08 Apr 2019 05:38:09 -0400
Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43160)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>)
	id 1hDQj3-0004vg-PQ; Mon, 08 Apr 2019 05:38:03 -0400
Original-Received: from [176.12.198.195] (port=38110 helo=[10.208.135.60])
	by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.82) (envelope-from <eliz@gnu.org>)
	id 1hDQj3-00084W-4Q; Mon, 08 Apr 2019 05:38:01 -0400
In-Reply-To: <m2r2ac9b5m.wl%esq@lawlist.com>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:235110
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/235110>

On April 8, 2019 11:03:17 AM GMT+03:00, Keith David Bershatsky <esq@lawlist=
=2Ecom> wrote:
> Thank you, Paul, for taking the time to try and reproduce the behavior
> that I am experiencing on my end=2E
>=20
> I am assuming that this round of tests is with a current version of
> the master branch (0b8117ed1abfc17bb0bc1690a8997736f1e8f98c) and
> _after_ applying the x=2Ediff patch=2E  I built the Emacs master branch
> (current version) without any modifications so that the build could
> complete without errors, and then I applied the x=2Ediff patch and built
> again and then performed the gdb test=2E  The build with the patch will
> crash on my end when garbage collection occurs; however, the ptype
> test is able to complete and I have attached a gdb printout
> 0b8117ed1abfc17bb0bc1690a8997736f1e8f98c=2Etxt=2E  The current issue is
> beyond my current level of programming abilities to resolve, so other
> than performing a standard M-x diff between your ptype test (relabeled
> as ptype_by_paul=2Etxt) and my own test
> (0b8117ed1abfc17bb0bc1690a8997736f1e8f98c=2Etxt), I would need further
> guidance regarding how best to be of assistance=2E
>=20
> My setup on Windows XP SP-3 didn't recognize a build option of -m32,
> so I just used the same old build options that I have used previously;
> i=2Ee=2E,:
>=20
> CFLAGS=3D'-O0 -g3' =2E/configure \
> --enable-checking=3D'yes,glyphs' \
> --enable-check-lisp-object-type \
> --without-compress-install \
> --without-makeinfo \
> --with-gnutls=3Dno \
> --with-mailutils \
> --without-makeinfo
>=20
> Keith
>=20
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>=20
> > Date: [04-07-2019 22:23:07] <7 Apr 2019 22:23:07 -0700>
> > From: Paul Eggert <eggert@cs=2Eucla=2Eedu>
> > To: Keith David Bershatsky <esq@lawlist=2Ecom>
> > Cc: emacs-devel@gnu=2Eorg, Stefan Monnier <monnier@iro=2Eumontreal=2Ec=
a>,
> > Andreas Schwab <schwab@linux-m68k=2Eorg>, Alan Mackenzie <acm@muc=2Ede=
>,
> > Daniel Colascione <dancol@dancol=2Eorg>
> > Subject: Re: buffer=2Ec/buffer=2Eh: How to add new buffer-local
> variables?
> >=20
> > Keith David Bershatsky wrote:
> > > Perhaps there is something that may stand out (to a trained
> programmer) in the 01/31/2019 commit =2E=2E=2E=2E
> >=20
> > It did change the buffer struct layout, so it's a good candidate for
> a culprit=2E
> >=20
> > For what it's worth, I cannot reproduce the problem in a 32-bit
> build under Fedora 29 x86-64 (GCC 8=2E3=2E1)=2E I configured this way:
> >=20
> > =2E/configure CC=3Dgcc -m32 -march=3Dnative --enable-gcc-warnings
> --without-imagemagick --without-gif --with-modules
> --enable-checking=3Dyes,glyphs --enable-check-lisp-object-type
> --with-gnutls=3Dno
> >=20
> > and built Emacs master with the attached patch x=2Ediff=2E
> >=20
> > My guess is that the problem has something to do with the unportable
> assumptions we've long made about struct buffer layout=2E I am attaching
> ptype=2Etxt, the output of the GDB command "ptype /o current_buffer"
> that Eli suggested; please compare it to your ptype output=2E

The problem is caused by the 4-byte hole between the last Lisp_Object memb=
er of the buffer structure and the beginning of struct buffer_text=2E  It c=
auses us to decide that a buffer has 83 Lisp components, whereas it actuall=
y has only 82=2E  The hole is left uninitialized, and causes the segfault w=
hen we try to use it as a valid object=2E

I guess we need to make BUFFER_LISP_SIZE smarter?