Subject: bug#66151: 29.1.50; daemon crashing after X forwarding disconnects

From: Po Lu <[email-masked]>
Date: Sat, 13 Apr 2024 09:51:49 +0800

George P <[email-masked]> writes:

> Here is the new trace:
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x0000000000537fb2 in realize_default_face (f=0x9ff1650) at xfaces.c:5864
> 5864          XSETFONT (font_object, FRAME_FONT (f));
> Missing separate debuginfos, use: dnf debuginfo-install
> GConf2-3.2.6-22.el8.x86_64 bzip2-libs-1.0.6-26.el8.x86_64
> cairo-1.15.12-6.el8.x86_64 dbus-glib-0.110-2.el8.x86_64
> dbus-libs-1.12.8-26.el8.x86_64 dconf-0.28.0-4.el8.x86_64
> expat-2.2.5-11.el8.x86_64 fontconfig-2.13.1-4.el8.x86_64
> freetype-2.9.1-9.el8.x86_64 glib2-2.56.4-161.el8.x86_64
> gmp-6.1.2-10.el8.x86_64 gnutls-3.6.16-8.el8_9.1.x86_64
> graphite2-1.3.10-10.el8.x86_64 harfbuzz-1.7.5-3.el8.x86_64
> jbigkit-libs-2.1-14.el8.x86_64 libICE-1.0.9-15.el8.x86_64
> libSM-1.2.3-1.el8.x86_64 libX11-1.6.8-6.el8.x86_64
> libX11-xcb-1.6.8-6.el8.x86_64 libXau-1.0.9-3.el8.x86_64
> libXaw-1.0.13-10.el8.x86_64 libXcomposite-0.4.4-14.el8.x86_64
> libXcursor-1.1.15-3.el8.x86_64 libXfixes-5.0.3-7.el8.x86_64
> libXi-1.7.10-1.el8.x86_64 libXinerama-1.1.4-1.el8.x86_64
> libXmu-1.1.3-1.el8.x86_64 libXpm-3.5.12-9.el8_7.x86_64
> libXrandr-1.5.2-1.el8.x86_64 libXrender-0.9.10-7.el8.x86_64
> libXt-1.1.5-12.el8.x86_64 libacl-2.2.53-1.el8.x86_64
> libattr-2.4.48-3.el8.x86_64 libblkid-2.32.1-43.el8.x86_64
> libcap-2.48-6.el8_9.x86_64 libffi-3.1-24.el8.x86_64
> libgcrypt-1.8.5-7.el8_6.x86_64 libgpg-error-1.31-1.el8.x86_64
> libjpeg-turbo-1.5.3-12.el8.x86_64 libmount-2.32.1-43.el8.x86_64
> libpng-1.6.34-5.el8.x86_64 libselinux-2.9-8.el8.x86_64
> libtasn1-4.13-4.el8_7.x86_64 libtiff-4.0.9-29.el8_8.x86_64
> libunistring-0.9.9-3.el8.x86_64 libuuid-2.32.1-43.el8.x86_64
> libwebp-1.0.0-9.el8_9.1.x86_64 libxcb-1.13.1-1.el8.x86_64
> libxml2-2.9.7-9.el8.11.deshaw.x86_64 lz4-libs-1.8.3-3.el8_4.x86_64
> nettle-3.4.1-7.el8.x86_64 p11-kit-0.23.22-1.el8.x86_64
> pcre-8.42-6.el8.x86_64 pcre2-10.32-3.el8_6.x86_64
> sqlite-libs-3.26.0-19.el8_9.x86_64 systemd-libs-239-78.el8.x86_64
> zlib-1.2.11-25.el8.x86_64
> (gdb) where
> #0  0x0000000000537fb2 in realize_default_face (f=0x9ff1650) at xfaces.c:5864
> #1  0x0000000000537c3e in realize_basic_faces (f=0x9ff1650) at xfaces.c:5798
> #2  0x000000000052aced in recompute_basic_faces (f=0x9ff1650) at xfaces.c:719
> #3  0x000000000071d794 in free_realized_fontsets (base=0x7fffec5a731d)
> at fontset.c:1372
> #4  0x000000000071ebf7 in Fset_fontset_font (fontset=0x30,
> characters=0x7fffeb3b7bc3, font_spec=0x15e66cd, frame=0xf3a095,
> add=0x0) at fontset.c:1720
> #5  0x000000000066ba2f in eval_sub (form=0x7fffeb3b7be3) at eval.c:2539
> #6  0x000000000066b1d3 in Feval (form=0x7fffeb3b7be3, lexical=0x30) at
> eval.c:2389
> #7  0x000000000066d170 in funcall_subr (subr=0xce3580 <Seval>,
> numargs=2, args=0x7fffebd4c1b0) at eval.c:3092
> #8  0x00000000006bf470 in exec_byte_code (fun=0x7fffec2b86e5,
> args_template=513, nargs=2, args=0x7fffebd4c4c0) at bytecode.c:814
> #9  0x000000000066d76e in funcall_lambda (fun=0x2c39e95, nargs=0,
> arg_vector=0x7fffffffba60) at eval.c:3194
> #10 0x000000000066cc24 in funcall_general (fun=0x2c39e95, numargs=0,
> args=0x7fffffffba60) at eval.c:2972
> #11 0x000000000066cea9 in Ffuncall (nargs=1, args=0x7fffffffba58) at eval.c:3022
> #12 0x0000000000665f0c in call0 (fn=0x2c39e95) at lisp.h:3503
> #13 0x0000000000668dcb in Fhandler_bind_1 (nargs=3,
> args=0x7fffebd4c128) at eval.c:1403
> #14 0x000000000066d369 in funcall_subr (subr=0xce3440
> <Shandler_bind_1>, numargs=3, args=0x7fffebd4c128) at eval.c:3113
> #15 0x00000000006bf470 in exec_byte_code (fun=0x7fffec2b17e5,
> args_template=1025, nargs=4, args=0x7fffffffc2c0) at bytecode.c:814
> #16 0x000000000066d76e in funcall_lambda (fun=0x7fffec2b17e5, nargs=4,
> arg_vector=0x7fffffffc2a0) at eval.c:3194
> #17 0x000000000066cc24 in funcall_general (fun=0x7fffec2b17e5,
> numargs=4, args=0x7fffffffc2a0) at eval.c:2972
> #18 0x000000000066cea9 in Ffuncall (nargs=5, args=0x7fffffffc298) at eval.c:3022
> #19 0x0000000000662c69 in Ffuncall_interactively (nargs=5,
> args=0x7fffffffc298) at callint.c:250
> #20 0x000000000066d369 in funcall_subr (subr=0xce2cc0
> <Sfuncall_interactively>, numargs=5, args=0x7fffffffc298) at
> eval.c:3113
> #21 0x000000000066cbd8 in funcall_general (fun=0xce2cc5
> <Sfuncall_interactively+5>, numargs=5, args=0x7fffffffc298) at
> eval.c:2968
> #22 0x000000000066cea9 in Ffuncall (nargs=6, args=0x7fffffffc290) at eval.c:3022
> #23 0x000000000066c358 in Fapply (nargs=3, args=0x7fffffffc3d0) at eval.c:2693
> #24 0x0000000000663085 in Fcall_interactively
> (function=0x7fffeb5542f0, record_flag=0x0, keys=0x70ae4a5) at
> callint.c:342
> #25 0x000000000066d19f in funcall_subr (subr=0xce2d00
> <Scall_interactively>, numargs=3, args=0x7fffebd4c070) at eval.c:3094
> #26 0x00000000006bf470 in exec_byte_code (fun=0x7fffec92a33d,
> args_template=1025, nargs=1, args=0x7fffffffcda0) at bytecode.c:814
> #27 0x000000000066d76e in funcall_lambda (fun=0x7fffec92a33d, nargs=1,
> arg_vector=0x7fffffffcd98) at eval.c:3194
> #28 0x000000000066cc24 in funcall_general (fun=0x7fffec92a33d,
> numargs=1, args=0x7fffffffcd98) at eval.c:2972
> #29 0x000000000066cea9 in Ffuncall (nargs=2, args=0x7fffffffcd90) at eval.c:3022
> #30 0x00000000005aac1f in command_loop_1 () at keyboard.c:1549
> #31 0x0000000000669463 in internal_condition_case (bfun=0x5aa419
> <command_loop_1>, handlers=0x90, hfun=0x5a99e3 <cmd_error>) at
> eval.c:1537
> #32 0x00000000005aa088 in command_loop_2 (handlers=0x90) at keyboard.c:1167
> #33 0x000000000066897e in internal_catch (tag=0x10c20, func=0x5aa065
> <command_loop_2>, arg=0x90) at eval.c:1217
> #34 0x00000000005aa020 in command_loop () at keyboard.c:1145
> #35 0x00000000005a9592 in recursive_edit_1 () at keyboard.c:753
> #36 0x00000000005a973a in Frecursive_edit () at keyboard.c:836
> #37 0x00000000005a5c81 in main (argc=2, argv=0x7fffffffd1e8) at emacs.c:2618
> (gdb) print f->output_data
> $1 = {tty = 0x0, x = 0x0, w32 = 0x0, ns = 0x0, pgtk = 0x0, haiku =
> 0x0, android = 0x0}
>
> This is using the master branch on commit
> 0fab2649e288c7a350018293443e709eba6b0fe2. Let me know if you want me
> to do more digging in gdb.

Yes please--this backtrace doesn't convey enough information to
establish when the disconnect is first detected, so please place another
breakpoint on `x_io_error_quitter', repeat this exercise, and post
backtraces from both the new and the existing breakpoint.