Re: buffer.c/buffer.h: How to add new buffer-local variables?

[Eli Zaretskii]

On April 8, 2019 11:03:17 AM GMT+03:00, Keith David Bershatsky <address@hidden> 
wrote:
> Thank you, Paul, for taking the time to try and reproduce the behavior
> that I am experiencing on my end.
> 
> I am assuming that this round of tests is with a current version of
> the master branch (0b8117ed1abfc17bb0bc1690a8997736f1e8f98c) and
> _after_ applying the x.diff patch.  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.diff patch and built
> again and then performed the gdb test.  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.txt.  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.txt) and my own test
> (0b8117ed1abfc17bb0bc1690a8997736f1e8f98c.txt), I would need further
> guidance regarding how best to be of assistance.
> 
> 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.e.,:
> 
> CFLAGS='-O0 -g3' ./configure \
> --enable-checking='yes,glyphs' \
> --enable-check-lisp-object-type \
> --without-compress-install \
> --without-makeinfo \
> --with-gnutls=no \
> --with-mailutils \
> --without-makeinfo
> 
> Keith
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> > Date: [04-07-2019 22:23:07] <7 Apr 2019 22:23:07 -0700>
> > From: Paul Eggert <address@hidden>
> > To: Keith David Bershatsky <address@hidden>
> > Cc: address@hidden, Stefan Monnier <address@hidden>,
> > Andreas Schwab <address@hidden>, Alan Mackenzie <address@hidden>,
> > Daniel Colascione <address@hidden>
> > Subject: Re: buffer.c/buffer.h: How to add new buffer-local
> variables?
> > 
> > Keith David Bershatsky wrote:
> > > Perhaps there is something that may stand out (to a trained
> programmer) in the 01/31/2019 commit ....
> > 
> > It did change the buffer struct layout, so it's a good candidate for
> a culprit.
> > 
> > For what it's worth, I cannot reproduce the problem in a 32-bit
> build under Fedora 29 x86-64 (GCC 8.3.1). I configured this way:
> > 
> > ./configure CC=gcc -m32 -march=native --enable-gcc-warnings
> --without-imagemagick --without-gif --with-modules
> --enable-checking=yes,glyphs --enable-check-lisp-object-type
> --with-gnutls=no
> > 
> > and built Emacs master with the attached patch x.diff.
> > 
> > My guess is that the problem has something to do with the unportable
> assumptions we've long made about struct buffer layout. I am attaching
> ptype.txt, the output of the GDB command "ptype /o current_buffer"
> that Eli suggested; please compare it to your ptype output.

The problem is caused by the 4-byte hole between the last Lisp_Object member of 
the buffer structure and the beginning of struct buffer_text.  It causes us to 
decide that a buffer has 83 Lisp components, whereas it actually has only 82.  
The hole is left uninitialized, and causes the segfault when we try to use it 
as a valid object.

I guess we need to make BUFFER_LISP_SIZE smarter?