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

[andres . ramirez]

Hi. Po Lu.

>>>>> "Po" == Po Lu <luangruo@yahoo.com> writes:


[...]

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

Right. I got emacs running on synch mode. But on that case error does
NOT happen. Attached is the gdb log.

proper_backtrace_debug_on_and_synch.log
Description: debuglog

[...]

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

Right. It does not call emacs_abort. It calls kill-emacs -1 inside the
debug elisp function.

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

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

This is a very old emacs bug for me. It had took me years identifying
the right combination that triggers the bug.

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

As said above the backtrace is attached.

Best Regards