Emacs and LLD

[Tobias Kortkamp]

Hi,

I cannot build editors/emacs-nox11 (or any other Emacs port) on FreeBSD
12 anymore for several months now. The build aborts with:

./temacs --batch --load loadup bootstrap
Fatal error 'Can't allocate initial thread' at line 337 in file
/usr/src/lib/libthr/thread/thr_init.c (errno = 12)
gmake[3]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped)

I'm currently running base r324724. Emacs builds fine on the cluster,
so I thought installing the binary package from pkg.FreeBSD.org would be
an OK solution, but it immediately crashes too.

My src.conf has WITH_LLD_IS_LD=yes and reading
https://bugs.freebsd.org/214864 leads me to believe that it's somehow
responsible for the problems I have with Emacs.

Setting LLD_UNSAFE=yes in the port does not solve the problem. If I
manually link temacs statically the build can continue, however the
emacs binary temacs dumps is not usable and immediately crashes.

I can "solve" the problem (in the sense that I can run Emacs again
outside of a chroot/jail) by extracting /lib/libc.so.7 from a recent
snapshot (I tried with 20171012-r324542 and the current base.txz
snapshot) not built with LLD and running it with

LD_PRELOAD="/path/to/libc.so.7" emacs

It'll do for now, but this just doesn't feel right...

Thanks in advance for any insight you can provide!

Backtrace from temacs:

* thread #1, name = 'temacs', stop reason = signal SIGABRT
* frame #0: 0x0000000800e089aa libc.so.7`__sys_thr_kill at
thr_kill.S:3
frame #1: 0x0000000800e08974 libc.so.7`__raise(s=6) at raise.c:52
frame #2: 0x0000000800e088e9 libc.so.7`abort at abort.c:65
frame #3: 0x0000000800c8c88a
libthr.so.3`_thread_exitf(fname=<unavailable>, lineno=<unavailable>,
fmt=<unavailable>) at thr_exit.c:193
frame #4: 0x0000000800c8a02e
libthr.so.3`_libpthread_init(curthread=0x0000000000000000) at
thr_init.c:337
frame #5: 0x0000000800c8d4b2 libthr.so.3
frame #6: 0x0000000800c8d4d6 libthr.so.3`_init + 14
frame #7: 0x00000008007b0058
ld-elf.so.1`objlist_call_init(list=<unavailable>,
lockstate=<unavailable>) at rtld.c:2643
frame #8: 0x00000008007af3eb
ld-elf.so.1`_rtld(sp=0x00007fffffffdf08,
exit_proc=0x00007fffffffdeb0, objp=0x00007fffffffdeb8) at rtld.c:759
frame #9: 0x00000008007ad019 ld-elf.so.1`.rtld_start at
rtld_start.S:39

[Tobias Kortkamp]

Post by Tobias Kortkamp
Hi,
I cannot build editors/emacs-nox11 (or any other Emacs port) on FreeBSD
./temacs --batch --load loadup bootstrap
Fatal error 'Can't allocate initial thread' at line 337 in file
/usr/src/lib/libthr/thread/thr_init.c (errno = 12)
gmake[3]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped)
I'm currently running base r324724. Emacs builds fine on the cluster,
so I thought installing the binary package from pkg.FreeBSD.org would be
an OK solution, but it immediately crashes too.
My src.conf has WITH_LLD_IS_LD=yes and reading
https://bugs.freebsd.org/214864 leads me to believe that it's somehow
responsible for the problems I have with Emacs.
Setting LLD_UNSAFE=yes in the port does not solve the problem. If I
manually link temacs statically the build can continue, however the
emacs binary temacs dumps is not usable and immediately crashes.
I can "solve" the problem (in the sense that I can run Emacs again
outside of a chroot/jail) by extracting /lib/libc.so.7 from a recent
snapshot (I tried with 20171012-r324542 and the current base.txz
snapshot) not built with LLD and running it with
LD_PRELOAD="/path/to/libc.so.7" emacs
It'll do for now, but this just doesn't feel right...
Thanks in advance for any insight you can provide!
* thread #1, name = 'temacs', stop reason = signal SIGABRT
* frame #0: 0x0000000800e089aa libc.so.7`__sys_thr_kill at
thr_kill.S:3
frame #1: 0x0000000800e08974 libc.so.7`__raise(s=6) at raise.c:52
frame #2: 0x0000000800e088e9 libc.so.7`abort at abort.c:65
frame #3: 0x0000000800c8c88a
libthr.so.3`_thread_exitf(fname=<unavailable>, lineno=<unavailable>,
fmt=<unavailable>) at thr_exit.c:193
frame #4: 0x0000000800c8a02e
libthr.so.3`_libpthread_init(curthread=0x0000000000000000) at
thr_init.c:337
frame #5: 0x0000000800c8d4b2 libthr.so.3
frame #6: 0x0000000800c8d4d6 libthr.so.3`_init + 14
frame #7: 0x00000008007b0058
ld-elf.so.1`objlist_call_init(list=<unavailable>,
lockstate=<unavailable>) at rtld.c:2643
frame #8: 0x00000008007af3eb
ld-elf.so.1`_rtld(sp=0x00007fffffffdf08,
exit_proc=0x00007fffffffdeb0, objp=0x00007fffffffdeb8) at rtld.c:759
frame #9: 0x00000008007ad019 ld-elf.so.1`.rtld_start at
rtld_start.S:39
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

Hi,
security.bsd.stack_guard_page: 1
Does setting the above sysctl to zero make any difference?

No, unfortunately not.

[Ed Maste]

Post by Tobias Kortkamp
My src.conf has WITH_LLD_IS_LD=yes and reading
https://bugs.freebsd.org/214864 leads me to believe that it's somehow
responsible for the problems I have with Emacs.

Yes, the emacs build does some rather unusual things and it's perhaps
not surprising that it's one of the ports that's giving grief with
lld.

The exp-run shows the same error you experienced:

./temacs --batch --load loadup bootstrap
Fatal error 'Can't allocate initial thread' at line 337 in file
/poudriere/jails/headamd64PR214864/usr/src/lib/libthr/thread/thr_init.c
(errno = 12)
gmake[2]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped)

I don't yet have any insight into the failure, and hope that someone
with knowledge of the emacs build process and emacs internals can take
a look.

[Warner Losh]

Post by Ed Maste

Post by Tobias Kortkamp
My src.conf has WITH_LLD_IS_LD=yes and reading
https://bugs.freebsd.org/214864 leads me to believe that it's somehow
responsible for the problems I have with Emacs.

Yes, the emacs build does some rather unusual things and it's perhaps
not surprising that it's one of the ports that's giving grief with
lld.
./temacs --batch --load loadup bootstrap
Fatal error 'Can't allocate initial thread' at line 337 in file
/poudriere/jails/headamd64PR214864/usr/src/lib/libthr/thread/thr_init.c
(errno = 12)
gmake[2]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped)
I don't yet have any insight into the failure, and hope that someone
with knowledge of the emacs build process and emacs internals can take
a look.

Is temacs still an 'undumped' core dump[*]? Maybe the undumping code isn't
playing well with lld's different behavior than ld?

Warner

[*] For speed, emacs use to compile all its lisp, load it into a memory
arena, then take a core dump. The core dump was cleaned up so it could be
used as an executable with the now-preloaded lisp code in place. It was a
standard thing on 'big iron' that EMACS came from, but always a bit of an
'odd duck' as far as fitting into how Unix works. There used to be knobs to
do it differently for things like VMS that simply couldn't easily cope.
Maybe one of those needs to be tweaked? It's a tiny bit slower, but with
the speed of today's hardware (and most hardware made since ~2000), the
optimization likely saves time below the human threshold to detect...