GNU bug report logs - #71289
30.0.50; cmcheckmagic aborts when tty_write_glyphs writes "Garbage collecting..." in some cases

Previous Next

Full log

Message #77 received at 71289 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Clemente <n142857 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71289 <at> debbugs.gnu.org
Subject: Re: 30.0.50; cmcheckmagic aborts when tty_write_glyphs writes
 "Garbage collecting..." in some cases
Date: Thu, 6 Jun 2024 12:34:34 +0000

> So it is not exactly the same type of crash.
>
> In what scenario does this happen now?  IOW, what did you do to
> trigger those crashes?
>

I don't remember how the previous 2 crashes (BT1, BT2) happened. But I
just learnt to reproduce BT2 (in check_matrix_pointers), after 2 days
not being able to reproduce it.

The key to reproduce it to have 2 Emacs windows inside the frame:
1. Open emacs (no need for emacsclient) with -Q. No need to set
garbage-collection-messages to t
2. Do C-x 2 to have 2 windows, one above one below
3. Resize the X window to make it very small, (1 line or so)
4. It should immediately crash.

(gdb) bt full
#0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:443
No locals.
#1  0x00005555556bd41b in emacs_abort () at sysdep.c:2391
No locals.
#2  0x000055555558cb33 in check_matrix_pointers (window_matrix=0x5555588efa10,
    frame_matrix=0x5555595855c0) at dispnew.c:3129
        i = 0
        j = 0
#3  0x000055555558ca52 in check_window_matrix_pointers (w=0x5555591f66b8)
    at dispnew.c:3098
        f = 0x555558008768
#4  0x000055555558c9df in check_window_matrix_pointers (w=0x555559452b90)
    at dispnew.c:3094
No locals.
#5  0x000055555558c9df in check_window_matrix_pointers (w=0x55555960d2d8)
    at dispnew.c:3094
No locals.
#6  0x000055555558d10e in update_frame (f=0x555558008768, force_p=true,
    inhibit_hairy_id_p=false) at dispnew.c:3359
        paused_p = false
        root_window = 0x55555960d2d8
#7  0x00005555555cf68a in redisplay_internal () at xdisp.c:17464
        gcscrollbars = true
        f_redisplay_flag = true
        f = 0x555558008768
        w = 0x5555598dcd00
        sw = 0x5555598dcd00
        fr = 0x555558008768
        pending = false
        must_finish = true
        match_p = true
        tlbufpos = {
          charpos = 0,
          bytepos = 2275
        }
        tlendpos = {
          charpos = 614309,
          bytepos = 623747
        }
        number_of_visible_frames = 2
        sf = 0x555558008768
        polling_stopped_here = true
        tail = XIL(0x555558f6ae43)
        frame = XIL(0x55555800876d)
        MAX_HSCROLL_RETRIES = MAX_HSCROLL_RETRIES
        hscroll_retries = 0
        MAX_GARBAGED_FRAME_RETRIES = MAX_GARBAGED_FRAME_RETRIES
        garbaged_frame_retries = 0
        consider_all_windows_p = true
        update_miniwindow_p = true
        count = {
          bytes = 192
        }
#8  0x00005555555cffb0 in redisplay_preserve_echo_area (from_where=12)
at xdisp.c:17743
        count = {
          bytes = 160
        }
#9  0x00005555557eed00 in wait_reading_process_output (time_limit=0, nsecs=0,

> In what scenario does this happen now?  IOW, what did you do to
> trigger those crashes?
>
> I'd like to ask you to run that scenario with a watchpoint on the
> variable delayed_size_change, and the following two watchpoint
> commands:
>
>   bt 5
>   continue
>

Thanks, that's a very good way to track changes. I'll do it when I can
reproduce the crash/assert. Right now it seems to work fine (opening a
new frame: false→true then immediately true→false).



On Wed, 5 Jun 2024 at 15:06, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Daniel Clemente <n142857 <at> gmail.com>
> > Date: Wed, 5 Jun 2024 13:50:48 +0000
> > Cc: 71289 <at> debbugs.gnu.org
> >
> > With it (running on 799f78a92c6c31f4d181390523b83d036020ede1 with no
> > other changes), I still see the same types of crash that I already
> > reported: in tty_write_glyphs (see BT1 below) and in
> > build_frame_matrix_from_leaf_window (see BT2 below).
> > However they don't mention GC now.
>
> So it is not exactly the same type of crash.
>
> In what scenario does this happen now?  IOW, what did you do to
> trigger those crashes?
>
> I'd like to ask you to run that scenario with a watchpoint on the
> variable delayed_size_change, and the following two watchpoint
> commands:
>
>   bt 5
>   continue
>
> I hope the backtraces produced by this will explain who resets the
> delayed_size_change flag, seemingly prematurely(?), and might suggest
> ideas for a solution.  (I have an idea already, but would like to see
> some data to make sure the idea is solid.)
>
> It is best to run GDB in a separate terminal for this experiment.
> IOW, start Emacs, attach GDB to it from another terminal, say "set
> height 0" to let GDB scroll the output freely, then set up the
> watchpoint with the commands, and run Emacs with your recipe.
>
> Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.