recent master core dumps building on FreeBSD i386

recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

Hello,

A change within the last few days gives these core dumps on FreeBSD 10.4/11.2 i386.  Both 10.4 and 11.2 still build fine on amd64.  If I can find time this evening, I will try to drill down a commit.

http://pkg.awarnach.mathstat.dal.ca/data/10i386-default/2018-10-16_11h14m45s/logs/errors/emacs-devel-27.0.50.20181016,2.log
http://pkg.awarnach.mathstat.dal.ca/data/11i386-default/2018-10-16_11h14m45s/logs/errors/emacs-devel-27.0.50.20181016,2.log

-- Joseph

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

Joseph Mingrone <jrm@ftfl.ca> writes:

> Hello,

> A change within the last few days gives these core dumps on FreeBSD 10.4/11.2 i386.  Both 10.4 and 11.2 still build fine on amd64.  If I can find time this evening, I will try to drill down a commit.

> http://pkg.awarnach.mathstat.dal.ca/data/10i386-default/2018-10-16_11h14m45s/logs/errors/emacs-devel-27.0.50.20181016,2.log
> http://pkg.awarnach.mathstat.dal.ca/data/11i386-default/2018-10-16_11h14m45s/logs/errors/emacs-devel-27.0.50.20181016,2.log

> -- Joseph

As far as I can tell, the core dump began with f5896e2.

Build of f5896e2:
http://pkg.awarnach.mathstat.dal.ca/data/11i386-default/2018-10-16_22h12m56s/logs/errors/emacs-devel-27.0.50.20181016,2.log

Build of previous commit (643df6):
http://pkg.awarnach.mathstat.dal.ca/data/11i386-default/2018-10-16_22h06m14s/logs/errors/emacs-devel-27.0.50.20181016,2.log

There is an error creating a link at the end of the 643df6 build, but that seems to have been corrected.

-- Joseph

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: recent master core dumps building on FreeBSD i386

[Eli Zaretskii]

> From: Joseph Mingrone <jrm@ftfl.ca>
> Date: Tue, 16 Oct 2018 22:27:40 -0300
> 
> > A change within the last few days gives these core dumps on FreeBSD 10.4/11.2 i386.  Both 10.4 and 11.2 still build fine on amd64.  If I can find time this evening, I will try to drill down a commit.
> 
> > http://pkg.awarnach.mathstat.dal.ca/data/10i386-default/2018-10-16_11h14m45s/logs/errors/emacs-devel-27.0.50.20181016,2.log
> > http://pkg.awarnach.mathstat.dal.ca/data/11i386-default/2018-10-16_11h14m45s/logs/errors/emacs-devel-27.0.50.20181016,2.log
> 
> > -- Joseph
> 
> As far as I can tell, the core dump began with f5896e2.

This is unexpected.  Can you run the offending command under GDB and
show the backtrace from the crash, please?

Re: recent master core dumps building on FreeBSD i386

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On 10/17/18 9:10 AM, Eli Zaretskii wrote:
>> As far as I can tell, the core dump began with f5896e2.
> This is unexpected.  Can you run the offending command under GDB and
> show the backtrace from the crash, please?
>
Quite possibly this is yet another obscure bug involving dumping. I hope 
the portable dumper will be merged soon. Could you please remind me what 
the remaining trouble spots are with pdumper, i.e., the issues that are 
preventing merging that branch in?

Anyway, I struggled a bit with Joseph's report (trying lots of ways to 
build Emacs master on Fedora 28) and managed to reproduce a similar 
problem that does indeed involve dumping. I installed into Emacs master 
the attached patch, which fixed that bug for me. Joseph, please try the 
latest master, and if that doesn't work then GDB may well be your friend 
(though it may not be; dumping leads to reaaaally obscure problems).


[-- Attachment #2: 0001-Bring-back-nocombreloc-if-dumping.patch --]
[-- Type: text/x-patch, Size: 3402 bytes --]

From 3d67ec142099196df17a633da63e772fbe33b4fb Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 17 Oct 2018 17:55:43 -0700
Subject: [PATCH] Bring back nocombreloc if dumping

Without this patch, Emacs dumps core on Fedora 28 x86-64
when configured via "CC='gcc -m32' --enable-gcc-warnings
--without-imagemagick --without-gif --with-modules
PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig".
and then when run normally in a windowing system.
'make check' and 'emacs -nw' work OK even without the patch.
* configure.ac (LD_SWITCH_SYSTEM_TEMACS): Prepend
-znocombreloc if supported and if dumping.  This mostly
reverts 2018-06-15T21:37:39!eggert@cs.ucla.edu "Remove old
combreloc hack".
---
 configure.ac | 33 +++++++++++++++++++++++++++++++++
 etc/PROBLEMS | 12 ++++++++++++
 2 files changed, 45 insertions(+)

diff --git a/configure.ac b/configure.ac
index bfd9d5d177..3a61090902 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1336,6 +1336,37 @@ AC_DEFUN
     ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
 fi
 
+dnl On some platforms using GNU ld, linking temacs needs -znocombreloc.
+dnl Although this has something to do with dumping, the details are unknown.
+dnl If the flag is used but not needed,
+dnl Emacs should still work (albeit a bit more slowly),
+dnl so use the flag everywhere that it is supported.
+dnl When testing whether the flag works, treat GCC specially
+dnl since it just gives a non-fatal 'unrecognized option'
+dnl if not built to support GNU ld.
+if test "$GCC" = yes; then
+  LDFLAGS_NOCOMBRELOC="-Wl,-znocombreloc"
+else
+  LDFLAGS_NOCOMBRELOC="-znocombreloc"
+fi
+
+AC_CACHE_CHECK([for -znocombreloc], [emacs_cv_znocombreloc],
+  [if test "$CANNOT_DUMP" = "yes"; then
+     emacs_cv_znocombreloc='not needed'
+   else
+     save_LDFLAGS=$LDFLAGS
+     LDFLAGS="$LDFLAGS $LDFLAGS_NOCOMBRELOC"
+     AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
+       [emacs_cv_znocombreloc=yes], [emacs_cv_znocombreloc=no])
+     LDFLAGS=$save_LDFLAGS
+   fi])
+
+case $emacs_cv_znocombreloc in
+  no*)
+    LDFLAGS_NOCOMBRELOC= ;;
+esac
+
+
 AC_CACHE_CHECK([whether addresses are sanitized],
   [emacs_cv_sanitize_address],
   [AC_COMPILE_IFELSE(
@@ -5346,6 +5377,8 @@ AC_DEFUN
   esac
 fi
 
+LD_SWITCH_SYSTEM_TEMACS="$LDFLAGS_NOCOMBRELOC $LD_SWITCH_SYSTEM_TEMACS"
+
 AC_SUBST(LD_SWITCH_SYSTEM_TEMACS)
 
 ## Common for all window systems
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index eba3420fcb..6805e8733d 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -192,6 +192,18 @@ Upgrading to a newer version of Exceed has been reported to prevent
 these crashes.  You should consider switching to a free X server, such
 as Xming or Cygwin/X.
 
+** Emacs crashes with SIGSEGV in XtInitializeWidgetClass.
+
+It crashes on X, but runs fine when called with option "-nw".
+
+This has been observed when Emacs is linked with GNU ld but without passing
+the -z nocombreloc flag.  Emacs normally knows to pass the -z nocombreloc
+flag when needed, so if you come across a situation where the flag is
+necessary but missing, please report it via M-x report-emacs-bug.
+
+On platforms such as Solaris, you can also work around this problem by
+configuring your compiler to use the native linker instead of GNU ld.
+
 ** When Emacs is compiled with Gtk+, closing a display kills Emacs.
 
 There is a long-standing bug in GTK that prevents it from recovering
-- 
2.17.2

Re: recent master core dumps building on FreeBSD i386

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 17 Oct 2018 18:09:39 -0700
> 
> I hope the portable dumper will be merged soon. Could you please
> remind me what the remaining trouble spots are with pdumper, i.e.,
> the issues that are preventing merging that branch in?

This question seems to pop up every 3 months, and somehow people think
I remember the answer by heart ;-)

Here's what I found in the archives:

  http://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00924.html
  http://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00929.html

Note that the master branch acquired several fundamentally new
features in the meantime, such as bignums, Lisp-objects-as-pointers,
and changes in misc objects, which AFAIU will need pdumper support, so
merging the branch now will need more work than you see in the above 2
messages.

Thanks.

Re: recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 10/17/18 9:10 AM, Eli Zaretskii wrote:
>>> As far as I can tell, the core dump began with f5896e2.
>> This is unexpected.  Can you run the offending command under GDB and
>> show the backtrace from the crash, please?

> Quite possibly this is yet another obscure bug involving dumping. I hope the portable dumper will be merged soon. Could you please remind me what the remaining trouble spots are with pdumper, i.e., the
> issues that are preventing merging that branch in?

> Anyway, I struggled a bit with Joseph's report (trying lots of ways to build Emacs master on Fedora 28) and managed to reproduce a similar problem that does indeed involve dumping. I installed into Emacs
> master the attached patch, which fixed that bug for me. Joseph, please try the latest master, and if that doesn't work then GDB may well be your friend (though it may not be; dumping leads to reaaaally
> obscure problems).

The core dump still occurs with that commit (e511b9d).  With `CFLAGS+=-O0 -ggdb` the build completed without problems.  With just `CFLAGS+=-ggdb` it did core dump.  A back trace is below.

root@11i386-default:/wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src # /usr/local/bin/gdb ./temacs
GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd11.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./temacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = screen-256color
Breakpoint 1 at 0x81599de: file emacs.c, line 370.
Temporary breakpoint 2 at 0x8177f95: file sysdep.c, line 1080.
(gdb) run --batch --no-build-details --load loadup bootstrap
Starting program: /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src/temacs --batch --no-build-details --load loadup bootstrap

./lisp.h:1170: Emacs fatal error: assertion failed: TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
370       signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
#1  0x081b6b7b in die (msg=0x8280b68 "TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr", file=0x828071a "./lisp.h", line=1170) at alloc.c:7096
#2  0x08249a00 in make_lisp_ptr (type=Lisp_Vectorlike, ptr=<optimized out>) at ./lisp.h:1170
#3  syms_of_threads () at thread.c:1133
#4  0x0815b280 in main (argc=<optimized out>, argv=0xffffda6c) at emacs.c:1630
(gdb)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: recent master core dumps building on FreeBSD i386

[Eli Zaretskii]

> From: Joseph Mingrone <jrm@ftfl.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 18 Oct 2018 12:40:06 -0300
> 
> (gdb) run --batch --no-build-details --load loadup bootstrap
> Starting program: /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src/temacs --batch --no-build-details --load loadup bootstrap
> 
> ./lisp.h:1170: Emacs fatal error: assertion failed: TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr
> 
> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
> 370       signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
> #1  0x081b6b7b in die (msg=0x8280b68 "TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr", file=0x828071a "./lisp.h", line=1170) at alloc.c:7096
> #2  0x08249a00 in make_lisp_ptr (type=Lisp_Vectorlike, ptr=<optimized out>) at ./lisp.h:1170
> #3  syms_of_threads () at thread.c:1133
> #4  0x0815b280 in main (argc=<optimized out>, argv=0xffffda6c) at emacs.c:1630
> (gdb)

Alignment again?  It does here:

  XSETTHREAD (Vmain_thread, &main_thread);

Re: recent master core dumps building on FreeBSD i386

[Eli Zaretskii]

> From: Joseph Mingrone <jrm@ftfl.ca>
> Date: Thu, 18 Oct 2018 12:40:06 -0300
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> ./lisp.h:1170: Emacs fatal error: assertion failed: TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr
> 
> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
> 370       signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
> #1  0x081b6b7b in die (msg=0x8280b68 "TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr", file=0x828071a "./lisp.h", line=1170) at alloc.c:7096
> #2  0x08249a00 in make_lisp_ptr (type=Lisp_Vectorlike, ptr=<optimized out>) at ./lisp.h:1170

Can you please repeat this experiment, and then, when it crashes, do
this:

  (gdb) source ./.gdbinit
  (gdb) frame 2
  (gdb) p/x a
  (gdb) xtype

and show us the results?

Thanks.

Re: recent master core dumps building on FreeBSD i386

[Eli Zaretskii]

> Date: Thu, 18 Oct 2018 18:56:06 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> It does here:
> 
>   XSETTHREAD (Vmain_thread, &main_thread);

Argh, I meant "dies".

Re: recent master core dumps building on FreeBSD i386

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On 10/18/18 9:02 AM, Eli Zaretskii wrote:
> Can you please repeat this experiment, and then, when it crashes, do
> this:
>
>    (gdb) source ./.gdbinit
>    (gdb) frame 2
>    (gdb) p/x a
>    (gdb) xtype
>
> and show us the results?

Also, please try these GDB commands when debugging ./temacs:

b syms_of_threads
r -Q
p &main_thread
disas syms_of_threads
p &Vmain_thread

I'm attaching the output of these commands on Fedora 28 x86-64 compiled 
with 'gcc -m32 -march=native -g3 -O2' (AMD Phenom II X4 910e). Evidently 
your compiler (clang?) is not inlining make_lisp_ptr, but it's still 
useful to know what it's up to. I see that GCC optimizes away not only 
the call to make_lisp_ptr, but also the runtime check 'TAGGEDP (a, type) 
&& XUNTAG (a, type, char) == ptr', I guess because GCC knows that 
main_thread is properly aligned so TAGGEDP must succeed here. clang 
isn't smart enough to do this sort of optimization (at least on Fedora) 
so if you're using clang that might partly explain the problem.

Also, please investigate what the macro GCALIGNED_STRUCT expands to. You 
can use 'gcc -E' to do that.


[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 4494 bytes --]

(gdb) b syms_of_threads
Breakpoint 1 at 0x8245e40: file thread.c, line 1097.
(gdb) r -Q
Starting program: /home/eggert/src/gnu/emacs/master-tmp/src/temacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, syms_of_threads () at thread.c:1097
(gdb) p &main_thread
$1 = (struct thread_state *) 0x85f2920 <main_thread>
(gdb) disas syms_of_threads
Dump of assembler code for function syms_of_threads:
=> 0x08245e40 <+0>:	push   %ebx
   0x08245e41 <+1>:	sub    $0x14,%esp
   0x08245e44 <+4>:	push   $0x8597340
   0x08245e49 <+9>:	call   0x8203e00 <defsubr>
   0x08245e4e <+14>:	movl   $0x8597320,(%esp)
   0x08245e55 <+21>:	call   0x8203e00 <defsubr>
   0x08245e5a <+26>:	movl   $0x8597300,(%esp)
   0x08245e61 <+33>:	call   0x8203e00 <defsubr>
   0x08245e66 <+38>:	movl   $0x85972e0,(%esp)
   0x08245e6d <+45>:	call   0x8203e00 <defsubr>
   0x08245e72 <+50>:	movl   $0x85972c0,(%esp)
   0x08245e79 <+57>:	call   0x8203e00 <defsubr>
   0x08245e7e <+62>:	movl   $0x85972a0,(%esp)
   0x08245e85 <+69>:	call   0x8203e00 <defsubr>
   0x08245e8a <+74>:	movl   $0x8597260,(%esp)
   0x08245e91 <+81>:	call   0x8203e00 <defsubr>
   0x08245e96 <+86>:	movl   $0x8597280,(%esp)
   0x08245e9d <+93>:	call   0x8203e00 <defsubr>
   0x08245ea2 <+98>:	movl   $0x8597240,(%esp)
   0x08245ea9 <+105>:	call   0x8203e00 <defsubr>
   0x08245eae <+110>:	movl   $0x8597460,(%esp)
   0x08245eb5 <+117>:	call   0x8203e00 <defsubr>
   0x08245eba <+122>:	movl   $0x8597440,(%esp)
   0x08245ec1 <+129>:	call   0x8203e00 <defsubr>
   0x08245ec6 <+134>:	movl   $0x8597420,(%esp)
   0x08245ecd <+141>:	call   0x8203e00 <defsubr>
   0x08245ed2 <+146>:	movl   $0x8597400,(%esp)
   0x08245ed9 <+153>:	call   0x8203e00 <defsubr>
   0x08245ede <+158>:	movl   $0x85973e0,(%esp)
   0x08245ee5 <+165>:	call   0x8203e00 <defsubr>
   0x08245eea <+170>:	movl   $0x85973c0,(%esp)
   0x08245ef1 <+177>:	call   0x8203e00 <defsubr>
   0x08245ef6 <+182>:	movl   $0x85973a0,(%esp)
   0x08245efd <+189>:	call   0x8203e00 <defsubr>
   0x08245f02 <+194>:	movl   $0x8597380,(%esp)
   0x08245f09 <+201>:	call   0x8203e00 <defsubr>
   0x08245f0e <+206>:	movl   $0x8597360,(%esp)
   0x08245f15 <+213>:	call   0x8203e00 <defsubr>
   0x08245f1a <+218>:	movl   $0x8597220,(%esp)
   0x08245f21 <+225>:	call   0x8203e00 <defsubr>
   0x08245f26 <+230>:	movl   $0x85f28e8,(%esp)
   0x08245f2d <+237>:	call   0x81b17a0 <staticpro>
   0x08245f32 <+242>:	pop    %edx
   0x08245f33 <+243>:	pop    %ecx
   0x08245f34 <+244>:	push   $0xd
   0x08245f36 <+246>:	push   $0x82acace
   0x08245f3b <+251>:	movl   $0x0,0x85f28e8
   0x08245f45 <+261>:	call   0x81ff540 <intern_c_string_1>
   0x08245f4a <+266>:	mov    %eax,%ebx
   0x08245f4c <+268>:	pop    %eax
   0x08245f4d <+269>:	pop    %edx
   0x08245f4e <+270>:	push   $0xe
   0x08245f50 <+272>:	push   $0x82acadc
   0x08245f55 <+277>:	call   0x81ff540 <intern_c_string_1>
   0x08245f5a <+282>:	add    $0xc,%esp
   0x08245f5d <+285>:	push   $0x0
   0x08245f5f <+287>:	push   %ebx
   0x08245f60 <+288>:	push   %eax
   0x08245f61 <+289>:	call   0x81b9d00 <Fdefalias>
   0x08245f66 <+294>:	pop    %ecx
   0x08245f67 <+295>:	pop    %ebx
   0x08245f68 <+296>:	push   $0x7
   0x08245f6a <+298>:	push   $0x82acb0d
   0x08245f6f <+303>:	call   0x81ff540 <intern_c_string_1>
   0x08245f74 <+308>:	pop    %edx
   0x08245f75 <+309>:	pop    %ecx
   0x08245f76 <+310>:	push   $0x0
   0x08245f78 <+312>:	push   %eax
   0x08245f79 <+313>:	call   0x81e15e0 <Fprovide>
   0x08245f7e <+318>:	add    $0xc,%esp
   0x08245f81 <+321>:	push   $0x85df124
   0x08245f86 <+326>:	push   $0x82acaeb
   0x08245f8b <+331>:	push   $0x85f28e0
   0x08245f90 <+336>:	call   0x82040e0 <defvar_lisp>
   0x08245f95 <+341>:	add    $0x10,%esp
   0x08245f98 <+344>:	cmpb   $0x0,0x85d64e0
   0x08245f9f <+351>:	movl   $0x85f2925,0x85df124
   0x08245fa9 <+361>:	jne    0x8245fbc <syms_of_threads+380>
   0x08245fab <+363>:	mov    0x85f2920,%eax
   0x08245fb0 <+368>:	and    $0x7f000000,%eax
   0x08245fb5 <+373>:	cmp    $0x54000000,%eax
   0x08245fba <+378>:	jne    0x8245fc1 <syms_of_threads+385>
   0x08245fbc <+380>:	add    $0x8,%esp
   0x08245fbf <+383>:	pop    %ebx
   0x08245fc0 <+384>:	ret
   0x08245fc1 <+385>:	push   %eax
   0x08245fc2 <+386>:	push   $0x46d
   0x08245fc7 <+391>:	push   $0x82acbfb
   0x08245fcc <+396>:	push   $0x82ac968
   0x08245fd1 <+401>:	call   0x81b1820 <die>
End of assembler dump.
(gdb) p &Vmain_thread
$2 = (Lisp_Object *) 0x85df124 <globals+740>
(gdb)

Re: recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 8522 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joseph Mingrone <jrm@ftfl.ca>
>> Date: Thu, 18 Oct 2018 12:40:06 -0300
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org

>> ./lisp.h:1170: Emacs fatal error: assertion failed: TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr

>> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
>> 370       signal (sig, SIG_DFL);
>> (gdb) bt
>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
>> #1  0x081b6b7b in die (msg=0x8280b68 "TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr", file=0x828071a "./lisp.h", line=1170) at alloc.c:7096
>> #2  0x08249a00 in make_lisp_ptr (type=Lisp_Vectorlike, ptr=<optimized out>) at ./lisp.h:1170

> Can you please repeat this experiment, and then, when it crashes, do
> this:

>   (gdb) source ./.gdbinit
>   (gdb) frame 2
>   (gdb) p/x a
>   (gdb) xtype

> and show us the results?

> Thanks.

root@11i386-default:/wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src # /usr/local/bin/gdb ./temacs
GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd11.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./temacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = screen-256color
Breakpoint 1 at 0x81599de: file emacs.c, line 370.
Temporary breakpoint 2 at 0x8177f95: file sysdep.c, line 1080.
(gdb) run --batch --no-build-details --load loadup bootstrap
Starting program: /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src/temacs --batch --no-build-details --load loadup bootstrap

./lisp.h:1170: Emacs fatal error: assertion failed: TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
370       signal (sig, SIG_DFL);
(gdb) source ./.gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Redefine command "xgetptr"? (y or n) [answered Y; input not from terminal]
Redefine command "xgetint"? (y or n) [answered Y; input not from terminal]
Redefine command "xgettype"? (y or n) [answered Y; input not from terminal]
Redefine command "xgetsym"? (y or n) [answered Y; input not from terminal]
Redefine command "xsymname"? (y or n) [answered Y; input not from terminal]
Redefine command "pr"? (y or n) [answered Y; input not from terminal]
Redefine command "pp"? (y or n) [answered Y; input not from terminal]
Redefine command "pv"? (y or n) [answered Y; input not from terminal]
Redefine command "xfmt"? (y or n) [answered Y; input not from terminal]
Redefine command "ppt"? (y or n) [answered Y; input not from terminal]
Redefine command "pitmethod"? (y or n) [answered Y; input not from terminal]
Redefine command "pitx"? (y or n) [answered Y; input not from terminal]
Redefine command "pit"? (y or n) [answered Y; input not from terminal]
Redefine command "prowx"? (y or n) [answered Y; input not from terminal]
Redefine command "prow"? (y or n) [answered Y; input not from terminal]
Redefine command "pcursorx"? (y or n) [answered Y; input not from terminal]
Redefine command "pcursor"? (y or n) [answered Y; input not from terminal]
Redefine command "pwinx"? (y or n) [answered Y; input not from terminal]
Redefine command "pwin"? (y or n) [answered Y; input not from terminal]
Redefine command "pbiditype"? (y or n) [answered Y; input not from terminal]
Redefine command "pgx"? (y or n) [answered Y; input not from terminal]
Redefine command "pg"? (y or n) [answered Y; input not from terminal]
Redefine command "pgi"? (y or n) [answered Y; input not from terminal]
Redefine command "pgn"? (y or n) [answered Y; input not from terminal]
Redefine command "pgrowx"? (y or n) [answered Y; input not from terminal]
Redefine command "pgrow"? (y or n) [answered Y; input not from terminal]
Redefine command "pgrowit"? (y or n) [answered Y; input not from terminal]
Redefine command "prowlims"? (y or n) [answered Y; input not from terminal]
Redefine command "pmtxrows"? (y or n) [answered Y; input not from terminal]
Redefine command "xtype"? (y or n) [answered Y; input not from terminal]
Redefine command "pvectype"? (y or n) [answered Y; input not from terminal]
Redefine command "xvectype"? (y or n) [answered Y; input not from terminal]
Redefine command "pvecsize"? (y or n) [answered Y; input not from terminal]
Redefine command "xvecsize"? (y or n) [answered Y; input not from terminal]
Redefine command "xint"? (y or n) [answered Y; input not from terminal]
Redefine command "xptr"? (y or n) [answered Y; input not from terminal]
Redefine command "xmarker"? (y or n) [answered Y; input not from terminal]
Redefine command "xoverlay"? (y or n) [answered Y; input not from terminal]
--Type <RET> for more, q to quit, c to continue without paging--
Redefine command "xsymbol"? (y or n) [answered Y; input not from terminal]
Redefine command "xstring"? (y or n) [answered Y; input not from terminal]
Redefine command "xvector"? (y or n) [answered Y; input not from terminal]
Redefine command "xprocess"? (y or n) [answered Y; input not from terminal]
Redefine command "xframe"? (y or n) [answered Y; input not from terminal]
Redefine command "xcompiled"? (y or n) [answered Y; input not from terminal]
Redefine command "xwindow"? (y or n) [answered Y; input not from terminal]
Redefine command "xwinconfig"? (y or n) [answered Y; input not from terminal]
Redefine command "xsubr"? (y or n) [answered Y; input not from terminal]
Redefine command "xchartable"? (y or n) [answered Y; input not from terminal]
Redefine command "xsubchartable"? (y or n) [answered Y; input not from terminal]
Redefine command "xboolvector"? (y or n) [answered Y; input not from terminal]
Redefine command "xbuffer"? (y or n) [answered Y; input not from terminal]
Redefine command "xhashtable"? (y or n) [answered Y; input not from terminal]
Redefine command "xcons"? (y or n) [answered Y; input not from terminal]
Redefine command "nextcons"? (y or n) [answered Y; input not from terminal]
Redefine command "xcar"? (y or n) [answered Y; input not from terminal]
Redefine command "xcdr"? (y or n) [answered Y; input not from terminal]
Redefine command "xlist"? (y or n) [answered Y; input not from terminal]
Redefine command "xfloat"? (y or n) [answered Y; input not from terminal]
Redefine command "xscrollbar"? (y or n) [answered Y; input not from terminal]
Redefine command "xpr"? (y or n) [answered Y; input not from terminal]
Redefine command "xprintstr"? (y or n) [answered Y; input not from terminal]
Redefine command "xprintsym"? (y or n) [answered Y; input not from terminal]
Redefine command "xcoding"? (y or n) [answered Y; input not from terminal]
Redefine command "xcharset"? (y or n) [answered Y; input not from terminal]
Redefine command "xfontset"? (y or n) [answered Y; input not from terminal]
Redefine command "xfont"? (y or n) [answered Y; input not from terminal]
Redefine command "xbacktrace"? (y or n) [answered Y; input not from terminal]
Redefine command "xprintbytestr"? (y or n) [answered Y; input not from terminal]
Redefine command "xwhichsymbols"? (y or n) [answered Y; input not from terminal]
Redefine command "hookpost-backtrace"? (y or n) [answered Y; input not from terminal]
Redefine command "ff"? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = screen-256color
Breakpoint 3 at 0x81599de: file emacs.c, line 370.
Temporary breakpoint 4 at 0x8177f95: file sysdep.c, line 1080.
(gdb) frame 2
#2  0x08249a00 in make_lisp_ptr (type=Lisp_Vectorlike, ptr=<optimized out>) at ./lisp.h:1170
1170      eassert (TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr);
(gdb) p/x a
$1 = <optimized out>
(gdb) xtype
value has been optimized out
(gdb)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 8517 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 10/18/18 9:02 AM, Eli Zaretskii wrote:
>> Can you please repeat this experiment, and then, when it crashes, do
>> this:

>>    (gdb) source ./.gdbinit
>>    (gdb) frame 2
>>    (gdb) p/x a
>>    (gdb) xtype

>> and show us the results?

> Also, please try these GDB commands when debugging ./temacs:

> b syms_of_threads
> r -Q
> p &main_thread
> disas syms_of_threads
> p &Vmain_thread

> I'm attaching the output of these commands on Fedora 28 x86-64 compiled with 'gcc -m32 -march=native -g3 -O2' (AMD Phenom II X4 910e). Evidently your compiler (clang?) is not inlining make_lisp_ptr, but
> it's still useful to know what it's up to. I see that GCC optimizes away not only the call to make_lisp_ptr, but also the runtime check 'TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr', I guess because
> GCC knows that main_thread is properly aligned so TAGGEDP must succeed here. clang isn't smart enough to do this sort of optimization (at least on Fedora) so if you're using clang that might partly explain
> the problem.

root@11i386-default:/wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src # /usr/local/bin/gdb ./temacs
GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd11.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./temacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = screen-256color
Breakpoint 1 at 0x81599de: file emacs.c, line 370.
Temporary breakpoint 2 at 0x8177f95: file sysdep.c, line 1080.
(gdb) b syms_of_threads
Breakpoint 3 at 0x8249851: file thread.c, line 1098.
(gdb) r -Q
Starting program: /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src/temacs -Q

Breakpoint 3, syms_of_threads () at thread.c:1098
1098          defsubr (&Smake_thread);
(gdb) p &main_thread
$1 = (struct thread_state *) 0x8554d0c <main_thread>
(gdb) disas syms_of_threads
Dump of assembler code for function syms_of_threads:
   0x08249840 <+0>:     push   %ebp
   0x08249841 <+1>:     mov    %esp,%ebp
   0x08249843 <+3>:     push   %esi
   0x08249844 <+4>:     push   $0x8506838
   0x08249849 <+9>:     call   0x8202e90 <defsubr>
   0x0824984e <+14>:    add    $0x4,%esp
=> 0x08249851 <+17>:    push   $0x8506898
   0x08249856 <+22>:    call   0x8202e90 <defsubr>
   0x0824985b <+27>:    add    $0x4,%esp
   0x0824985e <+30>:    push   $0x8506858
   0x08249863 <+35>:    call   0x8202e90 <defsubr>
   0x08249868 <+40>:    add    $0x4,%esp
   0x0824986b <+43>:    push   $0x85068b8
   0x08249870 <+48>:    call   0x8202e90 <defsubr>
   0x08249875 <+53>:    add    $0x4,%esp
   0x08249878 <+56>:    push   $0x85068d8
   0x0824987d <+61>:    call   0x8202e90 <defsubr>
   0x08249882 <+66>:    add    $0x4,%esp
   0x08249885 <+69>:    push   $0x85068f8
   0x0824988a <+74>:    call   0x8202e90 <defsubr>
   0x0824988f <+79>:    add    $0x4,%esp
   0x08249892 <+82>:    push   $0x8506918
   0x08249897 <+87>:    call   0x8202e90 <defsubr>
   0x0824989c <+92>:    add    $0x4,%esp
   0x0824989f <+95>:    push   $0x8506938
   0x082498a4 <+100>:   call   0x8202e90 <defsubr>
   0x082498a9 <+105>:   add    $0x4,%esp
   0x082498ac <+108>:   push   $0x8506878
   0x082498b1 <+113>:   call   0x8202e90 <defsubr>
   0x082498b6 <+118>:   add    $0x4,%esp
   0x082498b9 <+121>:   push   $0x8506958
   0x082498be <+126>:   call   0x8202e90 <defsubr>
   0x082498c3 <+131>:   add    $0x4,%esp
   0x082498c6 <+134>:   push   $0x8506978
   0x082498cb <+139>:   call   0x8202e90 <defsubr>
   0x082498d0 <+144>:   add    $0x4,%esp
   0x082498d3 <+147>:   push   $0x8506998
   0x082498d8 <+152>:   call   0x8202e90 <defsubr>
   0x082498dd <+157>:   add    $0x4,%esp
--Type <RET> for more, q to quit, c to continue without paging--
   0x082498e0 <+160>:   push   $0x85069b8
   0x082498e5 <+165>:   call   0x8202e90 <defsubr>
   0x082498ea <+170>:   add    $0x4,%esp
   0x082498ed <+173>:   push   $0x85069d8
   0x082498f2 <+178>:   call   0x8202e90 <defsubr>
   0x082498f7 <+183>:   add    $0x4,%esp
   0x082498fa <+186>:   push   $0x85069f8
   0x082498ff <+191>:   call   0x8202e90 <defsubr>
   0x08249904 <+196>:   add    $0x4,%esp
   0x08249907 <+199>:   push   $0x8506a18
   0x0824990c <+204>:   call   0x8202e90 <defsubr>
   0x08249911 <+209>:   add    $0x4,%esp
   0x08249914 <+212>:   push   $0x8506a38
   0x08249919 <+217>:   call   0x8202e90 <defsubr>
   0x0824991e <+222>:   add    $0x4,%esp
   0x08249921 <+225>:   push   $0x8506a58
   0x08249926 <+230>:   call   0x8202e90 <defsubr>
   0x0824992b <+235>:   add    $0x4,%esp
   0x0824992e <+238>:   push   $0x8506a78
   0x08249933 <+243>:   call   0x8202e90 <defsubr>
   0x08249938 <+248>:   add    $0x4,%esp
   0x0824993b <+251>:   push   $0x8554dc0
   0x08249940 <+256>:   call   0x81bad60 <staticpro>
   0x08249945 <+261>:   add    $0x4,%esp
   0x08249948 <+264>:   movl   $0x0,0x8554dc0
   0x08249952 <+274>:   push   $0xe
   0x08249954 <+276>:   push   $0x82ab272
   0x08249959 <+281>:   call   0x8202460 <intern_c_string_1>
   0x0824995e <+286>:   add    $0x8,%esp
   0x08249961 <+289>:   mov    %eax,%esi
   0x08249963 <+291>:   push   $0xd
   0x08249965 <+293>:   push   $0x82ab281
   0x0824996a <+298>:   call   0x8202460 <intern_c_string_1>
   0x0824996f <+303>:   add    $0x8,%esp
   0x08249972 <+306>:   push   $0x0
   0x08249974 <+308>:   push   %eax
   0x08249975 <+309>:   push   %esi
   0x08249976 <+310>:   call   0x81c0930 <Fdefalias>
   0x0824997b <+315>:   add    $0xc,%esp
   0x0824997e <+318>:   push   $0x7
--Type <RET> for more, q to quit, c to continue without paging--
   0x08249980 <+320>:   push   $0x82ab691
   0x08249985 <+325>:   call   0x8202460 <intern_c_string_1>
   0x0824998a <+330>:   add    $0x8,%esp
   0x0824998d <+333>:   push   $0x0
   0x0824998f <+335>:   push   %eax
   0x08249990 <+336>:   call   0x81e4ad0 <Fprovide>
   0x08249995 <+341>:   add    $0x8,%esp
   0x08249998 <+344>:   push   $0x8557a54
   0x0824999d <+349>:   push   $0x82ab28f
   0x082499a2 <+354>:   push   $0x8554dc8
   0x082499a7 <+359>:   call   0x82030f0 <defvar_lisp>
   0x082499ac <+364>:   add    $0xc,%esp
   0x082499af <+367>:   cmpb   $0x0,0x8557ef0
   0x082499b6 <+374>:   je     0x82499c4 <syms_of_threads+388>
   0x082499b8 <+376>:   movl   $0x8554d11,0x8557a54
   0x082499c2 <+386>:   jmp    0x82499e9 <syms_of_threads+425>
   0x082499c4 <+388>:   mov    $0x8554d14,%eax
   0x082499c9 <+393>:   test   $0x7,%al
   0x082499cb <+395>:   jne    0x82499ec <syms_of_threads+428>
   0x082499cd <+397>:   movl   $0x8554d11,0x8557a54
   0x082499d7 <+407>:   mov    $0x7f000000,%eax
   0x082499dc <+412>:   and    0x8554d0c,%eax
   0x082499e2 <+418>:   cmp    $0x54000000,%eax
   0x082499e7 <+423>:   jne    0x8249a00 <syms_of_threads+448>
   0x082499e9 <+425>:   pop    %esi
   0x082499ea <+426>:   pop    %ebp
   0x082499eb <+427>:   ret
   0x082499ec <+428>:   push   $0x492
   0x082499f1 <+433>:   push   $0x828071a
   0x082499f6 <+438>:   push   $0x8280b68
   0x082499fb <+443>:   call   0x81b6b50 <die>
   0x08249a00 <+448>:   push   $0x46d
   0x08249a05 <+453>:   push   $0x82ab73e
   0x08249a0a <+458>:   push   $0x82ab29b
   0x08249a0f <+463>:   call   0x81b6b50 <die>
End of assembler dump.
(gdb) p &Vmain_thread
No symbol "Vmain_thread" in current context.
(gdb) quit
A debugging session is active.

        Inferior 1 [process 86154] will be killed.

Quit anyway? (y or n) y

root@11i386-default:/wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-e511b9d/src # CC --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: i386-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

> Also, please investigate what the macro GCALIGNED_STRUCT expands to. You can use 'gcc -E' to do that.

I'll get back to you with this soon.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: recent master core dumps building on FreeBSD i386

[Paul Eggert]

On 10/18/18 12:09 PM, Joseph Mingrone wrote:
> (gdb) p &main_thread
> $1 = (struct thread_state *) 0x8554d0c <main_thread>

main_thread is not properly aligned; its address is a multiple of 4, but 
it should be a multiple of 8. That's the problem. Somehow 
GCALIGNED_STRUCT is not working on your platform.

Re: recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 10/18/18 9:02 AM, Eli Zaretskii wrote:
>> Can you please repeat this experiment, and then, when it crashes, do
>> this:

>>    (gdb) source ./.gdbinit
>>    (gdb) frame 2
>>    (gdb) p/x a
>>    (gdb) xtype

>> and show us the results?

> Also, please try these GDB commands when debugging ./temacs:

> b syms_of_threads
> r -Q
> p &main_thread
> disas syms_of_threads
> p &Vmain_thread

> I'm attaching the output of these commands on Fedora 28 x86-64 compiled with 'gcc -m32 -march=native -g3 -O2' (AMD Phenom II X4 910e). Evidently your compiler (clang?) is not inlining make_lisp_ptr, but
> it's still useful to know what it's up to. I see that GCC optimizes away not only the call to make_lisp_ptr, but also the runtime check 'TAGGEDP (a, type) && XUNTAG (a, type, char) == ptr', I guess because
> GCC knows that main_thread is properly aligned so TAGGEDP must succeed here. clang isn't smart enough to do this sort of optimization (at least on Fedora) so if you're using clang that might partly explain
> the problem.

> Also, please investigate what the macro GCALIGNED_STRUCT expands to. You can use 'gcc -E' to do that.

Is it still helpful for me to investigate what GCALIGNED_STRUCT expands to?  If so, could elaborate on how I can get this?

Paul Eggert <eggert@cs.ucla.edu> writes:
> main_thread is not properly aligned; its address is a multiple of 4, but it should be a multiple of 8. That's the problem. Somehow GCALIGNED_STRUCT is not working on your platform.

Is there anything else helpful for me to investigate or do you recommend that I report this problem elsewhere?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: recent master core dumps building on FreeBSD i386

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On 10/18/18 6:15 PM, Joseph Mingrone wrote:
> Is it still helpful for me to investigate what GCALIGNED_STRUCT expands to?  If so, could elaborate on how I can get this?

To get the expansion (but see below first), put the following into a 
file src/t.c:

#include <config.h>
#include <lisp.h>
"GCALIGNED_STRUCT" GCALIGNED_STRUCT

and then run 'cd src; cc -E -I. -I../lib t.c | tail -n1'. You probably 
need to adjust that command line to match the way you're building Emacs. 
My output with current master on Fedora x86-64 is:

"GCALIGNED_STRUCT" __attribute__ ((aligned (8)))


However, in thinking about this some more I do see a problem that could 
explain your symptoms, a problem that resulted from a merge from 
emacs-26 that collided with changes in the master without Git (or me) 
noticing the collision. I installed the attached patch into master to 
fix it. Please try this patch first, and we can worry about 
GCALIGNED_STRUCT only if this patch does not fix things for you.


[-- Attachment #2: 0001-Fix-struct-thread-alignment-on-FreeBSD-x86.txt --]
[-- Type: text/plain, Size: 9704 bytes --]

From 1b28be70c4fcb7145a1c9c76023638e26146315f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 19 Oct 2018 09:06:52 -0700
Subject: [PATCH] Fix struct thread alignment on FreeBSD x86
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Joseph Mingrone in:
https://lists.gnu.org/r/emacs-devel/2018-10/msg00238.html
While we’re at it, apply a similar fix to struct Lisp_Subr; this
removes the need for GCALIGNED_STRUCT_MEMBER and thus can shrink
struct Lisp_Subr a bit.
* configure.ac (HAVE_STRUCT_ATTRIBUTE_ALIGNED): Bring back this macro.
Although used only for performance (not to actually align
structures), we might as well take advantage of it.
* src/lisp.h (GCALIGNED_STRUCT_MEMBER): Remove; all uses removed.
(union Aligned_Lisp_Subr): New type, like struct Lisp_Subr but aligned.
* src/lisp.h (XSUBR, DEFUN):
* src/lread.c (defsubr): Use it.  All callers changed.
* src/thread.c (union aligned_thread_state): New type.
(main_thread): Now of this type, so it’s aligned.
All uses changed.
* src/xmenu.c (syms_of_xmenu) [USE_GTK || USE_X_TOOLKIT]:
Adjust to union Aligned_Lisp_Subr change.
---
 configure.ac | 16 ++++++++++++++++
 src/lisp.h   | 37 +++++++++++++++++++------------------
 src/lread.c  |  3 ++-
 src/thread.c | 47 +++++++++++++++++++++++++++--------------------
 src/xmenu.c  |  2 +-
 5 files changed, 65 insertions(+), 40 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3a61090902..50e3333528 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5207,6 +5207,22 @@ AC_DEFUN
 fi
 AC_SUBST(LIBXMENU)
 
+AC_CACHE_CHECK([for struct alignment],
+  [emacs_cv_struct_alignment],
+  [AC_COMPILE_IFELSE(
+     [AC_LANG_PROGRAM([[#include <stddef.h>
+			struct s { char c; } __attribute__ ((aligned (8)));
+			struct t { char c; struct s s; };
+			char verify[offsetof (struct t, s) == 8 ? 1 : -1];
+		      ]])],
+     [emacs_cv_struct_alignment=yes],
+     [emacs_cv_struct_alignment=no])])
+if test "$emacs_cv_struct_alignment" = yes; then
+  AC_DEFINE([HAVE_STRUCT_ATTRIBUTE_ALIGNED], 1,
+    [Define to 1 if 'struct __attribute__ ((aligned (N)))' aligns the
+     structure to an N-byte boundary.])
+fi
+
 if test "${GNU_MALLOC}" = "yes" ; then
   AC_DEFINE(GNU_MALLOC, 1,
 	    [Define to 1 if you want to use the GNU memory allocator.])
diff --git a/src/lisp.h b/src/lisp.h
index 145901dff5..eb6762678c 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -229,7 +229,7 @@ extern bool suppress_checking EXTERNALLY_VISIBLE;
    USE_LSB_TAG not only requires the least 3 bits of pointers returned by
    malloc to be 0 but also needs to be able to impose a mult-of-8 alignment
    on some non-GC Lisp_Objects, all of which are aligned via
-   GCALIGNED_UNION_MEMBER, GCALIGNED_STRUCT_MEMBER, and GCALIGNED_STRUCT.  */
+   GCALIGNED_UNION_MEMBER.  */
 
 enum Lisp_Bits
   {
@@ -284,15 +284,14 @@ error !;
 # define GCALIGNMENT 1
 #endif
 
-/* If a struct is always allocated by the GC and is therefore always
-   GC-aligned, put GCALIGNED_STRUCT after its closing '}'; this can
-   help the compiler generate better code.
+/* To cause a union to have alignment of at least GCALIGNMENT, put
+   GCALIGNED_UNION_MEMBER in its member list.
 
-   To cause a union to have alignment of at least GCALIGNMENT, put
-   GCALIGNED_UNION_MEMBER in its member list.  Similarly for a struct
-   and GCALIGNED_STRUCT_MEMBER, although this may make the struct a
-   bit bigger on non-GCC platforms.  Any struct using
-   GCALIGNED_STRUCT_MEMBER should also use GCALIGNED_STRUCT.
+   If a struct is always GC-aligned (either by the GC, or via
+   allocation in a containing union that has GCALIGNED_UNION_MEMBER)
+   and does not contain a GC-aligned struct or union, putting
+   GCALIGNED_STRUCT after its closing '}' can help the compiler
+   generate better code.
 
    Although these macros are reasonably portable, they are not
    guaranteed on non-GCC platforms, as C11 does not require support
@@ -306,10 +305,8 @@ error !;
 
 #define GCALIGNED_UNION_MEMBER char alignas (GCALIGNMENT) gcaligned;
 #if HAVE_STRUCT_ATTRIBUTE_ALIGNED
-# define GCALIGNED_STRUCT_MEMBER
 # define GCALIGNED_STRUCT __attribute__ ((aligned (GCALIGNMENT)))
 #else
-# define GCALIGNED_STRUCT_MEMBER GCALIGNED_UNION_MEMBER
 # define GCALIGNED_STRUCT
 #endif
 #define GCALIGNED(type) (alignof (type) % GCALIGNMENT == 0)
@@ -1970,9 +1967,13 @@ struct Lisp_Subr
     const char *symbol_name;
     const char *intspec;
     EMACS_INT doc;
-    GCALIGNED_STRUCT_MEMBER
   } GCALIGNED_STRUCT;
-verify (GCALIGNED (struct Lisp_Subr));
+union Aligned_Lisp_Subr
+  {
+    struct Lisp_Subr s;
+    GCALIGNED_UNION_MEMBER
+  };
+verify (GCALIGNED (union Aligned_Lisp_Subr));
 
 INLINE bool
 SUBRP (Lisp_Object a)
@@ -1984,7 +1985,7 @@ INLINE struct Lisp_Subr *
 XSUBR (Lisp_Object a)
 {
   eassert (SUBRP (a));
-  return XUNTAG (a, Lisp_Vectorlike, struct Lisp_Subr);
+  return &XUNTAG (a, Lisp_Vectorlike, union Aligned_Lisp_Subr)->s;
 }
 
 enum char_table_specials
@@ -2952,15 +2953,15 @@ CHECK_FIXNUM_CDR (Lisp_Object x)
 /* This version of DEFUN declares a function prototype with the right
    arguments, so we can catch errors with maxargs at compile-time.  */
 #define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc)	\
-   static struct Lisp_Subr sname =				\
-     { { PVEC_SUBR << PSEUDOVECTOR_AREA_BITS },				\
+   static union Aligned_Lisp_Subr sname =				\
+     {{{ PVEC_SUBR << PSEUDOVECTOR_AREA_BITS },				\
        { .a ## maxargs = fnname },					\
-       minargs, maxargs, lname, intspec, 0};				\
+       minargs, maxargs, lname, intspec, 0}};				\
    Lisp_Object fnname
 
 /* defsubr (Sname);
    is how we define the symbol for function `name' at start-up time.  */
-extern void defsubr (struct Lisp_Subr *);
+extern void defsubr (union Aligned_Lisp_Subr *);
 
 enum maxargs
   {
diff --git a/src/lread.c b/src/lread.c
index 62616cb681..5f3871436d 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4409,8 +4409,9 @@ init_obarray (void)
 }
 \f
 void
-defsubr (struct Lisp_Subr *sname)
+defsubr (union Aligned_Lisp_Subr *aname)
 {
+  struct Lisp_Subr *sname = &aname->s;
   Lisp_Object sym, tem;
   sym = intern_c_string (sname->symbol_name);
   XSETPVECTYPE (sname, PVEC_SUBR);
diff --git a/src/thread.c b/src/thread.c
index 3674af0e47..6612697b95 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -27,11 +27,18 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 #include "syssignal.h"
 #include "keyboard.h"
 
-static struct thread_state main_thread;
+union aligned_thread_state
+{
+  struct thread_state s;
+  GCALIGNED_UNION_MEMBER
+};
+verify (GCALIGNED (union aligned_thread_state));
+
+static union aligned_thread_state main_thread;
 
-struct thread_state *current_thread = &main_thread;
+struct thread_state *current_thread = &main_thread.s;
 
-static struct thread_state *all_threads = &main_thread;
+static struct thread_state *all_threads = &main_thread.s;
 
 static sys_mutex_t global_lock;
 
@@ -113,7 +120,7 @@ maybe_reacquire_global_lock (void)
   /* SIGINT handler is always run on the main thread, see
      deliver_process_signal, so reflect that in our thread-tracking
      variables.  */
-  current_thread = &main_thread;
+  current_thread = &main_thread.s;
 
   if (current_thread->not_holding_lock)
     {
@@ -659,7 +666,7 @@ mark_threads (void)
 void
 unmark_main_thread (void)
 {
-  main_thread.header.size &= ~ARRAY_MARK_FLAG;
+  main_thread.s.header.size &= ~ARRAY_MARK_FLAG;
 }
 
 \f
@@ -1043,23 +1050,23 @@ thread_check_current_buffer (struct buffer *buffer)
 static void
 init_main_thread (void)
 {
-  main_thread.header.size
+  main_thread.s.header.size
     = PSEUDOVECSIZE (struct thread_state, m_stack_bottom);
-  XSETPVECTYPE (&main_thread, PVEC_THREAD);
-  main_thread.m_last_thing_searched = Qnil;
-  main_thread.m_saved_last_thing_searched = Qnil;
-  main_thread.name = Qnil;
-  main_thread.function = Qnil;
-  main_thread.result = Qnil;
-  main_thread.error_symbol = Qnil;
-  main_thread.error_data = Qnil;
-  main_thread.event_object = Qnil;
+  XSETPVECTYPE (&main_thread.s, PVEC_THREAD);
+  main_thread.s.m_last_thing_searched = Qnil;
+  main_thread.s.m_saved_last_thing_searched = Qnil;
+  main_thread.s.name = Qnil;
+  main_thread.s.function = Qnil;
+  main_thread.s.result = Qnil;
+  main_thread.s.error_symbol = Qnil;
+  main_thread.s.error_data = Qnil;
+  main_thread.s.event_object = Qnil;
 }
 
 bool
 main_thread_p (void *ptr)
 {
-  return ptr == &main_thread;
+  return ptr == &main_thread.s;
 }
 
 bool
@@ -1080,11 +1087,11 @@ void
 init_threads (void)
 {
   init_main_thread ();
-  sys_cond_init (&main_thread.thread_condvar);
+  sys_cond_init (&main_thread.s.thread_condvar);
   sys_mutex_init (&global_lock);
   sys_mutex_lock (&global_lock);
-  current_thread = &main_thread;
-  main_thread.thread_id = sys_thread_self ();
+  current_thread = &main_thread.s;
+  main_thread.s.thread_id = sys_thread_self ();
 }
 
 void
@@ -1130,7 +1137,7 @@ syms_of_threads (void)
   DEFVAR_LISP ("main-thread", Vmain_thread,
     doc: /* The main thread of Emacs.  */);
 #ifdef THREADS_ENABLED
-  XSETTHREAD (Vmain_thread, &main_thread);
+  XSETTHREAD (Vmain_thread, &main_thread.s);
 #else
   Vmain_thread = Qnil;
 #endif
diff --git a/src/xmenu.c b/src/xmenu.c
index 10e882af43..31034f7112 100644
--- a/src/xmenu.c
+++ b/src/xmenu.c
@@ -2420,6 +2420,6 @@ syms_of_xmenu (void)
 #if defined (USE_GTK) || defined (USE_X_TOOLKIT)
   defsubr (&Sx_menu_bar_open_internal);
   Ffset (intern_c_string ("accelerate-menu"),
-	 intern_c_string (Sx_menu_bar_open_internal.symbol_name));
+	 intern_c_string (Sx_menu_bar_open_internal.s.symbol_name));
 #endif
 }
-- 
2.17.2

Re: recent master core dumps building on FreeBSD i386

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 10/18/18 6:15 PM, Joseph Mingrone wrote:
>> Is it still helpful for me to investigate what GCALIGNED_STRUCT expands to?  If so, could elaborate on how I can get this?

> To get the expansion (but see below first), put the following into a file src/t.c:

> #include <config.h>
> #include <lisp.h>
> "GCALIGNED_STRUCT" GCALIGNED_STRUCT

> and then run 'cd src; cc -E -I. -I../lib t.c | tail -n1'. You probably need to adjust that command line to match the way you're building Emacs. My output with current master on Fedora x86-64 is:

> "GCALIGNED_STRUCT" __attribute__ ((aligned (8)))


> However, in thinking about this some more I do see a problem that could explain your symptoms, a problem that resulted from a merge from emacs-26 that collided with changes in the master without Git (or
> me) noticing the collision. I installed the attached patch into master to fix it. Please try this patch first, and we can worry about GCALIGNED_STRUCT only if this patch does not fix things for you.

Hi Paul,

That works.
http://pkg.awarnach.mathstat.dal.ca/data/11i386-default/2018-10-19_14h24m35s/logs/emacs-devel-27.0.50.20181018,2.log

The FreeBSD emacs-devel package is updated, so this can get wider testing.
https://svnweb.freebsd.org/ports?view=revision&revision=482447

Thank you.

--
Joseph

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]