Re: help needed for getting a backtrace ( multi-head emacs_abort on lucid-frame)

[Po Lu]

Andrés Ramírez <rrandresf@gmail.com> writes:

> Hi.
>
> The first time I used the --daemon command line option I got:
> ,---- [  ]
> | Warning: due to a long standing Gtk+ bug
> | https://gitlab.gnome.org/GNOME/gtk/issues/221
> | Emacs might crash when run in daemon mode and the X11 connection is 
> unexpectedly lost.
> | Using an Emacs configured with --with-x-toolkit=lucid does not have this 
> problem.
> | Starting Emacs daemon.
> `----
>
> The output of that message lead me to the lucid toolkit.
>
> Also the first time I did M-x report-emacs-bug I got:
> ,---- [  ]
> | Please describe exactly what actions triggered the bug
> | and the precise symptoms of the bug.  If you can, give
> | a recipe starting from `emacs -Q':
> `----
>
> That's the reason for trying to get a proper backtrace for this case.
>
> Having said that this is the recipe for the missing backtrace:
> source code: emacs-28.1.tar.xz
> compiled emacs with: "--enable-checking=yes,glyphs 
> --enable-check-lisp-object-type 'CFLAGS=-O0 -g3' --with-cairo --with-harfbuzz 
> --with-modules --with-wide-int --with-x-toolkit=lucid --with-json=yes 
> --with-xft"

--with-xft has no effect when you specify --with-cairo, so I'll assume
you've actually built Emacs with cairo support.

Crystal ball says it's somehow related to that.

> 1. @host ./emacs  -Q -f toggle-debug-on-error --daemon
> 2. @host emacsclient -c -n --eval '(eshell)'
> 3. on eshell-buffer emacs-version Return 
> 4. @remoteMachine emacsclient -c -n ~/.bashrc {inside xterm} {JIC: be4 do 
> 'ssh -Y user@host'} {.bashrc could have just a comment character}
> 5. M-x dired-jump
> 6. M-x eval-expression "(x-synchronize t)" {without the quotes}{when doing 
> this step do not do #8}
> 7. M-x close-display-connection {both opened frames close, and emacs aborts. 
> check trying to open a new-frame}
> 8. type exit and press Return on xterm.  {this step depends on step#6}
>
> Expected Output:
> emacs crash {it's an emacs_abort}
> Both opened frames close. #2 and #4
>
> NOTE: when starting emacs without calling 'toggle-debug-on-error' after 
> step#7 when You open a new
> frame. You could get the message:
> 'X protocol error: RenderBadGlyph (invalid Glyph parameter) on protocol 
> request 139'
>
> For Trying to get backtrace I have appended those lines to the file
> /tmp/emacs/src/emacs-28.1/src/.gdbinit
>
> ,---- [  ]
> | #@theEndOf close-display-connection x-close-connection is called
> | # b  xfns.c:x-close-connection # does not work
> | b xterm.c:x_delete_terminal
> | b xterm.c:x_delete_display
> | b terminal.c:delete_terminal
> | b frame.c:delete_frame #very long function
> | b sysdep.c:emacs_abort
> | b emacs.c:terminate_due_to_signal
> `----
>
> Those breakpoints never get hitted.

The .gdbinit file defines commands in GDB which are useful for debugging
Emacs, but it is useless without attaching a debugger to Emacs in the
first place.