GNU bug report logs - #59147
29.0.50; dispnew.c:1456: Emacs fatal error: assertion failed: row >= 0 && row < matrix->nrows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregor Zattler <grfz <at> gmx.de>
Cc: 59147 <at> debbugs.gnu.org, notmuch <at> notmuchmail.org
Subject: bug#59147: 29.0.50; dispnew.c:1456: Emacs fatal error: assertion failed: row >= 0 && row < matrix->nrows
Date: Wed, 09 Nov 2022 16:43:47 +0200

> From: Gregor Zattler <grfz <at> gmx.de>
> Cc: bug-gnu-emacs <at> gnu.org, notmuch <at> notmuchmail.org
> Date: Wed, 09 Nov 2022 15:35:01 +0100
> 
> > The backtrace seems to indicate that it reads from the minibuffer, but
> > in that case, does it mean the mini-window was 7-lines high in this
> > case?
> 
> quite possible, I have quite a few saved searches which are
> presented to me.  The hight of the minibuffer also depends
> on the frames width.  If the frame is half of the width of
> my monitor the choices are listed in 6 lines, then there is
> a blan line and a final line with a prompt.  In fullscreen
> it's 3 lines of choices, the blank line and the prompt.
> 
> > Also, can you describe what you do to trigger this assertion
> > violation?
> 
> I can do so only on the level of user interaction: I call
> notmuch-jump-search via it's key binding which is key chord
> prefixed.  Then I enter one or more chars to select the
> specific saved search I want to perform.  It might be
> possible that I'm typing faster than Emacs performs this
> commands.  Emacs hits the assertion with the choices still
> visible.  I cannot say if it does so after my last key
> stroke or in the middel of them.

OK.  I installed a possible fix.  Can you update from Git, rebuild,
and see if it eliminates the assertions?

Previous Next

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