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

[Po Lu]

andrés ramírez <rrandresf@gmail.com> writes:

> I think that is equivalent to:
>
> ,---- [  ]
> | gdb -i=mi --args ./emacs -xrm "emacs.synchronous: true" -Q -f 
> toggle-debug-on-error --fg-daemon
> `----

I don't think anything you give via the command line applies when Emacs
is run as a daemon.  If that's what you did, it evidently didn't work,
since the errors are still coming from XPending.

> #23 0x00007ffff7bfc91a in _XEventsQueued () at /usr/lib/libX11.so.6
> #24 0x00007ffff7be8cc2 in XPending () at /usr/lib/libX11.so.6
> #25 0x0000555555703bc2 in XTread_socket (terminal=0x5555560361f8, 
> hold_quit=0x7fffffffc8c0) at ../../src/xterm.c:9492
> #26 0x00005555557554c7 in gobble_input () at ../../src/keyboard.c:6980

> IMO: There is more than one issue at the same time:
> 1. emacs should not abort when having debug-on-error on
> 2. close-display-connection should not close both frames.

Emacs does not abort when `debug-on-error' is on, and I don't see a call
to emacs_abort anywhere in those backtraces.

> 3. the X Glyph issue should not happen. Is it totally normal closing
> X-remote frames.

That is the only bug (which might be in Emacs, or some external library)
I see here.  Emacs 28 does not use rendering extension glyphs itself, so
it's more likely to be in cairo or some other library that we use.

Which is why a proper backtrace in synchronous mode is vital, so we can
know which code is making the offending protocol request: otherwise, the
errors are only reported the next time something calls XSync, some time
after the fautly code runs.

Thanks.