bug#64710: 29.0.92; desktop session on terminal with speedbar crash

[Eli Zaretskii]

> From: <johann.hoechtl@inhouse.wko.at>
> CC: <64710@debbugs.gnu.org>
> Date: Wed, 19 Jul 2023 06:38:22 +0000
> 
> The reason is actually not related to desktop-save. Unfortunately it is not 
> easy to reproduce, as the behavior is not consistent. With the following 
> recipe it shows quite regular though:
> 
> * Open a Windows Terminal, either Windows Terminal with bash or directly 
> cmd.exe; Didn't test with powershell.
> * Run emacs -Q -nw
> * M-x speedbar-get-focus
> * Right-click with the mouse, so the speedbar menu displays <-- this step 
> *seems* to trigger the bug more easily
> 
> Now the behavior is not consistent, either
> * Emacs enters a spin-lock and doesn't react; OR
> * Emacs crashes with a backtrace; OR
> * Emacs continues without any issues.

I cannot reproduce any problems with this recipe.  I tried many times,
and all I see is the drop-down menu drops and everything is OK.

Does this happen in any directory or just in some?  If some, can you
describe in more detail what is special about those directories and
what do you see after "M-x speedbar-get-focus"?

> I did however also notice in the past that Emacs on Windows (builds from 
> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-29/) had spurious 
> crashes on other places, albeit only when running with -nw. So there might be 
> a nasty (Windows - only) terminal display bug?

So maybe your build has a problem, or maybe the systems on which you
run Emacs somehow trigger a problem that doesn't happen elsewhere/

> I do attach the backtrace and hope that it might be useful.

Unfortunately, this kind of backtrace can only be interpreted on your
system.  If you have GNU Binutils installed, you can use the method
described in the node "Crashing" of the Emacs manual to produce file
names, function names, and line numbers from these addresses.