Re: Recent libX11 update broke emacs

On Mon, Aug 3, 2020 at 3:09 PM Niclas Zeising <[email protected]>
wrote:

> On 2020-08-03 19:07, Kevin Oberman wrote:
> > This is a weird problem and I'm uncertain if it is in libW11, x11-server,
> > or emacs. As a result, I'm crossposting to both lists.
> >
> > Yesterday, after upgrading libX11 and x11-server, I could no longer run
> > Emacs to an  X display. It crashed quickly with a segmentation error in
> the
> > pthread library. Oddly, I could run it to my local xserver from a remote
> > system.
>
> Where does the segfault occur before entering pthreads?

Here is a backtrace  with symbols:
* thread #1, name = 'emacs-28.0.50', stop reason = signal SIGSEGV
  * frame #0: 0x000000002dc8584a
    frame #1: 0x000000002dc83ca4
    frame #2: 0x0000000000374fc0
emacs`detect_coding_utf_16(coding=0x00000000f2ee705a,
detect_info=0x0000000009d690dc) at coding.c:0:4
    frame #3: 0x000000000039584e
emacs`encode_invocation_designation(charset=0x000000000039584e,
coding=0x000000000083da20, dst="", p_nchars=0x000000000000000b) at
coding.c:4273:15
    frame #4: 0x00000000003958c3
emacs`encode_invocation_designation(charset=0x000000000083e230,
coding=0x0000000000000000, dst="", p_nchars=0x000000000083da40) at
coding.c:4280:4
    frame #5: 0x0000000000393df9
emacs`coding_alloc_by_realloc(coding=0x0000000000393df9, bytes=8641104) at
coding.c:1012:7
    frame #6: 0x0000000000395906
emacs`encode_invocation_designation(charset=0x000000000083dec0,
coding=0x000000000083de40, dst="", p_nchars=0x000000000083da70) at
coding.c:4285:6
  thread #2, name = 'emacs-28.0.50', stop reason = signal SIGSEGV
    frame #0: 0x000000002dc2beda
    frame #1: 0x000000002c929a26
  thread #3, name = 'emacs-28.0.50', stop reason = signal SIGSEGV
    frame #0: 0x000000002dc2beda
    frame #1: 0x000000002c929a26
  thread #4, name = 'emacs-28.0.50', stop reason = signal SIGSEGV
    frame #0: 0x000000002dc2beda
    frame #1: 0x000000002c929a26

>
>
> > Rolling back the x11 server did not help nor did rolling back libX11 or
> > even both of them. I had to roll back libX11 first and build the server
> > with the old libX11. Rebuilding emacs with the new ports made no
> difference.
>
> Which version of the server did you build?  The patch to xorg-server is
> trivial, just switching out malloc for calloc have the memory 0
> initialized.  The patch to libX11 is rather more involved.
> It is possible that someone accidentally changed the ABI of libX11, I
> guess.  What happens if you use the version with just the security fixes
> (the version I committed first, and that was merged to the Q3 branch.)
>

The problem seems almost certainly with libX11, not xorg-server-1.20.8_3,1.
I had to build the server against the old libX11 to get emacs to run.
I am running 12-Stable of yesterday,  r363784, with GENERIC except using
SCHED_4BSD. I build ports on this system, so packages are not relevant.

> Since the old libX11 contains a very serious vulnerability, I  really hate
> > to leave it this way, but I also have a hard time getting anything done
> > without emacs. Nothing other than emacs seems to have a problem with this
>
> There is one commit after libX11 1.6.10, that takes care of a regression.
> Can you apply
>
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/93fce3f4e79cbc737d6468a4f68ba3de1b83953b
> on top of the libX11 1.6.10 update and see if that fixes anything?
>

No improvement.

>
> Regards
> --
> Niclas
>
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: [email protected]
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[email protected]"