bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Mon, 16 Aug 2021 02:10:33 +0800
> Cc: "44448@debbugs.gnu.org" <44448@debbugs.gnu.org>
> 
> I tried and the bug can happen with breakpoint set. Haven't got a backtrace 
> though.
> 
> I have several questions.
> 
> 1. I am not familiar with GDB. I set the breakpoint by "b signal_or_quit", is 
> that right?

Yes.

> 2. When I reached the breakpoint, "p current_buffer" gives me "No symbol 
> "current_buffer" in current
> context." How should I get the point position in current window?

I don't understand how this could happen.  current_buffer is a global
variable, it should be visible everywhere.  Is your Emacs built with
the -g3 switch (i.e. CFLAGS includes -g3)?  If not, please rebuild
with CFLAGS=-g3.

> 3. When the bug happens, the cursor doesn't jump before hitting the 
> breakpoint, but immediately after I
> continue using "c". Does this seem right? (I guess so)

Yes.  But you should define commands for the breakpoint, so that Emacs
keeps running.  Like this:

  (gdb) break signal_or_quit
  (gdb) commands
    > backtrace
    > print current_buffer->pt
    > continue
    > end

> Printing the backtrace is so slow that it freezes my desktop for a long time 
> (and I don't know if that's
> forever). I need a way to tell if the bug happens before I print the 
> backtrace (I think that's the 2nd question
> above), so I can make sure I am getting the right backtrace and leave my PC 
> there for a while.

I don't know how to tell that.  In my testing, I kept typing C-g until
I saw the buffer displayed at BOB, then stopped typing C-g and looked
at the last few (2 to 4) backtraces.  I think the backtraces that are
interesting are inside redisplay (under the function
redisplay_internal).

Printing backtrace should be fast enough, it definitely shouldn't
freeze anything.  It didn't freeze for me here.