bug#42832: 28.0.50; "Bus error" when compiling Emacs now on Debian bullseye

[Pip Cet]

On Wed, Aug 12, 2020 at 9:54 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
>
> > Same sysctl settings, too? In particular, address randomization
> > appears to be enabled, does this also happen if you disable it (echo 0
> > | sudo tee /proc/sys/kernel/randomize_va_space) ?
>
> Tried that now and rebuilt -- bus error in the same place, I think:
>
> #0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x0000555555597ad5 in terminate_due_to_signal
>     (sig=sig@entry=7, backtrace_limit=backtrace_limit@entry=40) at emacs.c:408
> #2  0x0000555555597f6b in handle_fatal_signal (sig=sig@entry=7)
>     at sysdep.c:1782
> #3  0x0000555555692d9d in deliver_thread_signal
>     (sig=7, handler=0x555555597f60 <handle_fatal_signal>) at sysdep.c:1756
> #4  0x0000555555692e89 in deliver_fatal_thread_signal (sig=<optimized out>)
>     at sysdep.c:1794
> #5  0x00007ffff5726140 in <signal handler called> ()
>     at /lib/x86_64-linux-gnu/libpthread.so.0
> #6  vector_marked_p (v=0xc000000018000000) at alloc.c:3859
> #7  mark_object (arg=<optimized out>) at alloc.c:6607
> #8  0x00005555556d6d7e in mark_vectorlike (header=0x555555c34f10)
>     at alloc.c:6280

I'm trying to reproduce your build environment vaguely, and while the
addresses don't match up perfectly that does indeed appear to be an
eagerly-rehashed hash table's ->hash vector.

This is a shot in the dark, but in my case, the table containing that
address is Vdbus_registered_objects_table. Can you check whether
that's true in your case, too? Something like "p
globals.f_Vdbus_registered_objects_table" in gdb (using the core dump
should be fine) should either produce 0x555555c34f15 or something
else. If it is dbus, can you try compiling without it?