GNU bug report logs - #44349
28.0.50; Assertion failure on macOS when resizing frame

Previous Next

Package: emacs;

Reported by: Philipp <p.stephani2 <at> gmail.com>

Date: Sat, 31 Oct 2020 15:53:01 UTC

Severity: normal

Found in versions 27.1, 28.0.50

Fixed in version 28.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44349 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com
Subject: bug#44349: 28.0.50; Assertion failure on macOS when resizing frame
Date: Sun, 29 Nov 2020 17:16:23 +0000
On Sun, Nov 29, 2020 at 05:10:03PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 28 Nov 2020 22:06:45 +0000
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: p.stephani2 <at> gmail.com, 44349 <at> debbugs.gnu.org
> > 
> > > Thanks!  Can we add tests for this?
> > 
> > I was wondering that. How do we add tests for internal C functions?
> 
> By calling Lisp functions which call them.  But maybe it isn't
> possible in this case.
> 
> Wait, isn't the use case which caused this bug report a suitable test
> for the change?

It requires a frame to be resized with the mouse, we don't have a way
of doing that from lisp.

I can't see any way of using lisp functions to test doprnt, it's
mostly used in formatting error messages and other small bits and pieces.

> > > Silently ignoring parts of input sounds ... unusual, so I wonder what
> > > would it take to avoid that.  How did the old code avoid this problem?
> > 
> > This situation can only be caused by calling doprnt with format_end
> > set to some point inside a multibyte character (it's a pointer).
> 
> Ah, okay.  In that case, I think ignoring the invalid sequence is OK,
> but let's document that in the function's commentary.

I think, having thought about it more, I'd prefer to just pass through
the malformed input. If we want to make sure that putting format_end
in the middle of a multibyte character doesn't break anything I think
we'd be better fixing doprnt_non_null_end to cut the string up neatly.

format_end isn't currently used anywhere in Emacs, so I don't know if
it's worth fixing, but I'll add a FIXME comment.

-- 
Alan Third




This bug report was last modified 4 years and 226 days ago.

Previous Next


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