Re: Emacs and LLD

On Fri, Nov 3, 2017, at 16:59, Hans Petter Selasky wrote:
> On 11/03/17 16:29, Tobias Kortkamp wrote:
> > 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
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> > 
> 
> Hi,
> 
> security.bsd.stack_guard_page: 1
> 
> Does setting the above sysctl to zero make any difference?

No, unfortunately not.