bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Philipp]

1. Compile Emacs with assertions enabled on macOS.
2. Start it in graphical mode.
3. Try to resize the frame by dragging the lower-right corner.

This will trigger an assertion failure

doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
Fatal error 6: Aborted
Abort trap: 6

LLDB backtrace:

doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
Process 21775 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff71cda33a libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff71cda33a <+10>: jae    0x7fff71cda344            ; <+20>
    0x7fff71cda33c <+12>: movq   %rax, %rdi
    0x7fff71cda33f <+15>: jmp    0x7fff71cd4629            ; cerror_nocancel
    0x7fff71cda344 <+20>: retq   
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff71cda33a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff71d96e60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff71bf193e libsystem_c.dylib`raise + 26
    frame #3: 0x0000000100bcae19 emacs`terminate_due_to_signal(sig=<unavailable>, backtrace_limit=<unavailable>) at emacs.c:408:3 [opt]
    frame #4: 0x0000000100bcb42d emacs`emacs_abort at sysdep.c:2280:3 [opt]
    frame #5: 0x0000000100aaab36 emacs`ns_term_shutdown(sig=6) at nsterm.m:5729:7 [opt]
    frame #6: 0x00000001005c7634 emacs`shut_down_emacs(sig=<unavailable>, stuff=<unavailable>) at emacs.c:2472:3 [opt]
    frame #7: 0x0000000100bcad30 emacs`terminate_due_to_signal(sig=6, backtrace_limit=<unavailable>) at emacs.c:391:11 [opt]
    frame #8: 0x0000000100bcb9d9 emacs`die(msg=<unavailable>, file=<unavailable>, line=<unavailable>) at alloc.c:7341:3 [opt]
    frame #9: 0x00000001009acf6f emacs`doprnt(buffer=<unavailable>, bufsize=9223372036854775797, format=<unavailable>, format_end=<unavailable>, ap=<unavailable>) at doprnt.c:493:4 [opt]
    frame #10: 0x00000001009adcfc emacs`esprintf(buf="*scratch*  ??????????????????????????????????????", format=<unavailable>) at doprnt.c:535:12 [opt]
    frame #11: 0x0000000100abc0d5 emacs`-[EmacsView windowWillResize:toSize:](self=<unavailable>, _cmd=<unavailable>, sender=<unavailable>, frameSize=<unavailable>) at nsterm.m:7286:2 [opt]
    frame #12: 0x00007fff34ed2737 AppKit`-[NSWindow _confirmSize:force:] + 323
    frame #13: 0x00007fff3581d006 AppKit`-[NSWindow(NSWindowResizing) _validFrameForFrame:resizedFromEdge:] + 94
    frame #14: 0x00007fff35176b8d AppKit`-[NSTitledFrame _validFrameForResizeFrame:fromResizeEdge:] + 425
    frame #15: 0x00007fff3581cf68 AppKit`-[NSWindow(NSWindowResizing) _commonValidFrameForResizeFrame:fromResizeEdge:] + 157
    frame #16: 0x00007fff35819cd5 AppKit`-[NSWindow(NSWindowResizing) _frame:resizedFromEdge:withDelta:withEvent:withState:] + 3531
    frame #17: 0x00007fff35176065 AppKit`-[NSWindow(NSWindowResizing) _resizeWithEvent:] + 2486
    frame #18: 0x00007fff3504bfe6 AppKit`-[NSTitledFrame attemptResizeWithEvent:] + 177
    frame #19: 0x00007fff3504bcc7 AppKit`-[NSThemeFrame handleMouseDown:] + 294
    frame #20: 0x00007fff350e9248 AppKit`-[NSThemeFrame mouseDown:] + 30
    frame #21: 0x00007fff34fce5f0 AppKit`-[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4914
    frame #22: 0x00007fff34f38e21 AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2612
    frame #23: 0x00007fff34f381c9 AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 349
    frame #24: 0x00007fff34f36554 AppKit`-[NSApplication(NSEvent) sendEvent:] + 352
    frame #25: 0x0000000100aab8e5 emacs`-[EmacsApp sendEvent:](self=<unavailable>, _cmd=<unavailable>, theEvent=<unavailable>) at nsterm.m:5902:3 [opt]
    frame #26: 0x00007fff34d835bf AppKit`-[NSApplication run] + 707
    frame #27: 0x0000000100aab09a emacs`-[EmacsApp run](self=<unavailable>, _cmd=<unavailable>) at nsterm.m:5771:9 [opt]
    frame #28: 0x0000000100aa67ee emacs`ns_select(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at nsterm.m:4861:3 [opt]
    frame #29: 0x000000010095e00d emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=<unavailable>, do_display=<unavailable>, wait_for_cell=<unavailable>, wait_proc=0x0000000000000000, just_wait_proc=<unavailable>) at process.c:5609:18 [opt]
    frame #30: 0x0000000100612281 emacs`kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) at keyboard.c:3874:4 [opt]
    frame #31: 0x00000001006110b7 emacs`read_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>, used_mouse_menu=<unavailable>) at keyboard.c:2160:7 [opt]
    frame #32: 0x00000001005ea5e3 emacs`read_decoded_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>) at keyboard.c:2224:11 [opt]
    frame #33: 0x00000001005e5b49 emacs`read_char(commandflag=1, map=(i = 0x0000629000019573), prev_event=(i = 0x0000000000000000), used_mouse_menu=<unavailable>, end_time=0x0000000000000000) at keyboard.c:2834:11 [opt]
    frame #34: 0x00000001005d8647 emacs`read_key_sequence(keybuf=<unavailable>, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9552:12 [opt]
    frame #35: 0x00000001005d3fd1 emacs`command_loop_1 at keyboard.c:1354:15 [opt]
    frame #36: 0x0000000100863be5 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1240), handlers=<unavailable>, hfun=(emacs`cmd_error at keyboard.c:923)) at eval.c:1359:25 [opt]
    frame #37: 0x000000010060fd68 emacs`command_loop_2(ignore=(i = 0x0000000000000000)) at keyboard.c:1095:11 [opt]
    frame #38: 0x00000001008629b6 emacs`internal_catch(tag=(i = 0x000000000000c990), func=(emacs`command_loop_2 at keyboard.c:1091), arg=(i = 0x0000000000000000)) at eval.c:1120:25 [opt]
    frame #39: 0x00000001005d14d0 emacs`command_loop at keyboard.c:1074:2 [opt]
    frame #40: 0x00000001005d11c9 emacs`recursive_edit_1 at keyboard.c:718:9 [opt]
    frame #41: 0x00000001005d189f emacs`Frecursive_edit at keyboard.c:790:3 [opt]
    frame #42: 0x00000001005ca4a6 emacs`main(argc=0, argv=<unavailable>) at emacs.c:2047:3 [opt]
    frame #43: 0x00007fff71b92cc9 libdyld.dylib`start + 1




In GNU Emacs 28.0.50 (build 89, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H2))
 of 2020-10-31
Repository revision: 283b8d274bd54192b3876ce8bf2930a096391839
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-g3 -O1 -fsanitize=address
 -fsanitize=undefined -fno-omit-frame-pointer''

Configured features:
JPEG TIFF GIF PNG NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS
MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap
thingatpt url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map url-vars
mailcap rx gnutls puny dbus xml subr-x seq byte-opt gv bytecomp
byte-compile cconv compile text-property-search comint ansi-color ring
cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 70870 3425)
 (symbols 48 8580 1)
 (strings 32 23868 1428)
 (string-bytes 1 780264)
 (vectors 16 14940)
 (vector-slots 8 197741 15083)
 (floats 8 26 26)
 (intervals 56 212 0)
 (buffers 992 10))

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Philipp Stephani]

Am Sa., 31. Okt. 2020 um 16:53 Uhr schrieb Philipp <p.stephani2@gmail.com>:
>
>
> 1. Compile Emacs with assertions enabled on macOS.
> 2. Start it in graphical mode.
> 3. Try to resize the frame by dragging the lower-right corner.
>
> This will trigger an assertion failure
>
> doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
> Fatal error 6: Aborted
> Abort trap: 6
>


Here's a better backtrace with fewer arguments optimized out:

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff71cda33a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff71d96e60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff71bf193e libsystem_c.dylib`raise + 26
    frame #3: 0x00000001004a8332 emacs`terminate_due_to_signal(sig=6,
backtrace_limit=40) at emacs.c:408:3
    frame #4: 0x00000001004a8743 emacs`emacs_abort at sysdep.c:2280:3
    frame #5: 0x000000010043b8d8 emacs`ns_term_shutdown(sig=6) at
nsterm.m:5729:7
    frame #6: 0x00000001001b3b89 emacs`shut_down_emacs(sig=6, stuff=(i
= 0x0000000000000000)) at emacs.c:2472:3
    frame #7: 0x00000001004a82ca emacs`terminate_due_to_signal(sig=6,
backtrace_limit=2147483647) at emacs.c:391:11
    frame #8: 0x00000001004a8bec emacs`die(msg="ASCII_CHAR_P
(fmtchar)", file="doprnt.c", line=493) at alloc.c:7341:3
    frame #9: 0x00000001003c9a9e emacs`doprnt(buffer="*scratch*  ",
bufsize=9223372036854775797, format="%s  —  (%d x %d)",
format_end=0x0000000000000000, ap=0x00007ffeefbfb750) at
doprnt.c:493:4
    frame #10: 0x00000001003ca54d emacs`esprintf(buf="*scratch*  ",
format="%s  —  (%d x %d)") at doprnt.c:535:12
    frame #11: 0x000000010044364f emacs`-[EmacsView
windowWillResize:toSize:](self=0x0000000101463a70,
_cmd="windowWillResize:toSize:", sender=0x0000000101464810,
frameSize=(width = 598, height = 570)) at nsterm.m:7286:2
    frame #12: 0x00007fff34ed2737 AppKit`-[NSWindow _confirmSize:force:] + 323
    frame #13: 0x00007fff3581d006 AppKit`-[NSWindow(NSWindowResizing)
_validFrameForFrame:resizedFromEdge:] + 94
    frame #14: 0x00007fff35176b8d AppKit`-[NSTitledFrame
_validFrameForResizeFrame:fromResizeEdge:] + 425
    frame #15: 0x00007fff3581cf68 AppKit`-[NSWindow(NSWindowResizing)
_commonValidFrameForResizeFrame:fromResizeEdge:] + 157
    frame #16: 0x00007fff35819cd5 AppKit`-[NSWindow(NSWindowResizing)
_frame:resizedFromEdge:withDelta:withEvent:withState:] + 3531
    frame #17: 0x00007fff35176065 AppKit`-[NSWindow(NSWindowResizing)
_resizeWithEvent:] + 2486
    frame #18: 0x00007fff3504bfe6 AppKit`-[NSTitledFrame
attemptResizeWithEvent:] + 177
    frame #19: 0x00007fff3504bcc7 AppKit`-[NSThemeFrame handleMouseDown:] + 294
    frame #20: 0x00007fff350e9248 AppKit`-[NSThemeFrame mouseDown:] + 30
    frame #21: 0x00007fff34fce5f0 AppKit`-[NSWindow(NSEventRouting)
_handleMouseDownEvent:isDelayedEvent:] + 4914
    frame #22: 0x00007fff34f38e21 AppKit`-[NSWindow(NSEventRouting)
_reallySendEvent:isDelayedEvent:] + 2612
    frame #23: 0x00007fff34f381c9 AppKit`-[NSWindow(NSEventRouting)
sendEvent:] + 349
    frame #24: 0x00007fff34f36554 AppKit`-[NSApplication(NSEvent)
sendEvent:] + 352
    frame #25: 0x000000010043be14 emacs`-[EmacsApp
sendEvent:](self=0x0000000101348bb0, _cmd="sendEvent:",
theEvent=0x0000000109a5b440) at nsterm.m:5902:3
    frame #26: 0x00007fff34d835bf AppKit`-[NSApplication run] + 707
    frame #27: 0x000000010043b98a emacs`-[EmacsApp
run](self=0x0000000101348bb0, _cmd="run") at nsterm.m:5771:9
    frame #28: 0x00000001004399ab emacs`ns_select(nfds=0,
readfds=0x00007ffeefbfd2c0, writefds=0x00007ffeefbfd240,
exceptfds=0x0000000000000000, timeout=0x00007ffeefbfd218,
sigmask=0x0000000000000000) at nsterm.m:4861:3
    frame #29: 0x000000010039c79b
emacs`wait_reading_process_output(time_limit=0, nsecs=0, read_kbd=-1,
do_display=true, wait_for_cell=(i = 0x0000000000000000),
wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5609:18
    frame #30: 0x00000001001de3a5
emacs`kbd_buffer_get_event(kbp=0x00007ffeefbfd640,
used_mouse_menu=0x00007ffeefbfea0f, end_time=0x0000000000000000) at
keyboard.c:3874:4
    frame #31: 0x00000001001dd624
emacs`read_event_from_main_queue(end_time=0x0000000000000000,
local_getcjmp=0x00007ffeefbfe3a0, used_mouse_menu=0x00007ffeefbfea0f)
at keyboard.c:2160:7
    frame #32: 0x00000001001c75a9
emacs`read_decoded_event_from_main_queue(end_time=0x0000000000000000,
local_getcjmp=0x00007ffeefbfe3a0, prev_event=(i = 0x0000000000000000),
used_mouse_menu=0x00007ffeefbfea0f) at keyboard.c:2224:11
    frame #33: 0x00000001001c33d0 emacs`read_char(commandflag=1,
map=(i = 0x0000000101863da3), prev_event=(i = 0x0000000000000000),
used_mouse_menu=0x00007ffeefbfea0f, end_time=0x0000000000000000) at
keyboard.c:2834:11
    frame #34: 0x00000001001bba4f
emacs`read_key_sequence(keybuf=0x00007ffeefbff030, prompt=(i =
0x0000000000000000), dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9552:12
    frame #35: 0x00000001001b9e52 emacs`command_loop_1 at keyboard.c:1354:15
    frame #36: 0x00000001002f38ef
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1240), handlers=(i = 0x0000000000000090),
hfun=(emacs`cmd_error at keyboard.c:923)) at eval.c:1359:25
    frame #37: 0x00000001001dc631 emacs`command_loop_2(ignore=(i =
0x0000000000000000)) at keyboard.c:1095:11
    frame #38: 0x00000001002f2cda emacs`internal_catch(tag=(i =
0x000000000000c990), func=(emacs`command_loop_2 at keyboard.c:1091),
arg=(i = 0x0000000000000000)) at eval.c:1120:25
    frame #39: 0x00000001001b8906 emacs`command_loop at keyboard.c:1074:2
    frame #40: 0x00000001001b8744 emacs`recursive_edit_1 at keyboard.c:718:9
    frame #41: 0x00000001001b8b76 emacs`Frecursive_edit at keyboard.c:790:3
    frame #42: 0x00000001001b57cf emacs`main(argc=2,
argv=0x00007ffeefbff6e0) at emacs.c:2047:3
    frame #43: 0x00007fff71b92cc9 libdyld.dylib`start + 1

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Philipp Stephani]

Am Sa., 31. Okt. 2020 um 16:57 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>     frame #10: 0x00000001003ca54d emacs`esprintf(buf="*scratch*  ",
> format="%s  —  (%d x %d)") at doprnt.c:535:12
>     frame #11: 0x000000010044364f emacs`-[EmacsView
> windowWillResize:toSize:](self=0x0000000101463a70,
> _cmd="windowWillResize:toSize:", sender=0x0000000101464810,
> frameSize=(width = 598, height = 570)) at nsterm.m:7286:2

The issue here is the non-ASCII format string. No idea whether that's
supposed to be supported or not.

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 31 Oct 2020 16:57:54 +0100
> 
> > doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
> > Fatal error 6: Aborted
> > Abort trap: 6

I cannot say I understand why that assertion is there.

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Philipp Stephani]

Am Sa., 31. Okt. 2020 um 17:35 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 31 Oct 2020 16:57:54 +0100
> >
> > > doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
> > > Fatal error 6: Aborted
> > > Abort trap: 6
>
> I cannot say I understand why that assertion is there.

Line 81 of doprnt.c states that non-ASCII characters aren't supported.
That would mean that nsterm.m can't use (only) esprintf to generate
the size hint when resizing.

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 31 Oct 2020 17:43:57 +0100
> Cc: 44349@debbugs.gnu.org
> 
> Am Sa., 31. Okt. 2020 um 17:35 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Sat, 31 Oct 2020 16:57:54 +0100
> > >
> > > > doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
> > > > Fatal error 6: Aborted
> > > > Abort trap: 6
> >
> > I cannot say I understand why that assertion is there.
> 
> Line 81 of doprnt.c states that non-ASCII characters aren't supported.

I don't see why we would want to enforce that, it sounds like a grave
limitation.  Maybe I'm missing some background here.  The version we
have on emacs-27 does support non-ASCII characters in the format.

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third]

On Sat, Oct 31, 2020 at 04:57:54PM +0100, Philipp Stephani wrote:
> Am Sa., 31. Okt. 2020 um 16:53 Uhr schrieb Philipp <p.stephani2@gmail.com>:
> >
> >
> > 1. Compile Emacs with assertions enabled on macOS.
> > 2. Start it in graphical mode.
> > 3. Try to resize the frame by dragging the lower-right corner.
> >
> > This will trigger an assertion failure
> >
> > doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
> > Fatal error 6: Aborted
> > Abort trap: 6
> >
<snip>
>     frame #8: 0x00000001004a8bec emacs`die(msg="ASCII_CHAR_P
> (fmtchar)", file="doprnt.c", line=493) at alloc.c:7341:3
>     frame #9: 0x00000001003c9a9e emacs`doprnt(buffer="*scratch*  ",
> bufsize=9223372036854775797, format="%s  —  (%d x %d)",
> format_end=0x0000000000000000, ap=0x00007ffeefbfb750) at
> doprnt.c:493:4
>     frame #10: 0x00000001003ca54d emacs`esprintf(buf="*scratch*  ",
> format="%s  —  (%d x %d)") at doprnt.c:535:12
>     frame #11: 0x000000010044364f emacs`-[EmacsView
> windowWillResize:toSize:](self=0x0000000101463a70,
> _cmd="windowWillResize:toSize:", sender=0x0000000101464810,
> frameSize=(width = 598, height = 570)) at nsterm.m:7286:2

Hmm, it's this line:

    esprintf (size_title, "%s  —  (%d x %d)", old_title, cols, rows);

where old_title is UTF8. What is the right thing to do here?
-- 
Alan Third

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third]

On Sun, Nov 01, 2020 at 12:55:29AM +0000, Alan Third wrote:
> 
> Hmm, it's this line:
> 
>     esprintf (size_title, "%s  —  (%d x %d)", old_title, cols, rows);
> 
> where old_title is UTF8. What is the right thing to do here?

ignore me, I'm away on the wrong track and you're way ahead of me anyway.
-- 
Alan Third

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> Hmm, it's this line:
>
>     esprintf (size_title, "%s  —  (%d x %d)", old_title, cols, rows);
>
> where old_title is UTF8. What is the right thing to do here?

Isn't the problem the EM DASH (—) in the format string itself?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On Sat, Oct 31, 2020 at 06:52:08PM +0200, Eli Zaretskii wrote:
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 31 Oct 2020 17:43:57 +0100
> > Cc: 44349@debbugs.gnu.org
> > 
> > Am Sa., 31. Okt. 2020 um 17:35 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> > >
> > > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > > Date: Sat, 31 Oct 2020 16:57:54 +0100
> > > >
> > > > > doprnt.c:493: Emacs fatal error: assertion failed: ASCII_CHAR_P (fmtchar)
> > > > > Fatal error 6: Aborted
> > > > > Abort trap: 6
> > >
> > > I cannot say I understand why that assertion is there.
> > 
> > Line 81 of doprnt.c states that non-ASCII characters aren't supported.
> 
> I don't see why we would want to enforce that, it sounds like a grave
> limitation.  Maybe I'm missing some background here.  The version we
> have on emacs-27 does support non-ASCII characters in the format.

Patch attached.

I can't see any other special cases that need to be handled and all my
tests worked, so I think this is all that's needed.

-- 
Alan Third

[-- Attachment #2: 0001-Allow-doprint-to-handle-multibyte-chars-in-format-bu.patch --]
[-- Type: text/plain, Size: 2101 bytes --]

From 7bf4318f34c77e90c76944ee28693a895baf1807 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Fri, 27 Nov 2020 22:11:47 +0000
Subject: [PATCH] Allow doprint to handle multibyte chars in format (bug#44349)

* src/doprnt.c (doprnt): Handle the case where fmtchar is the start of
a multibyte character.
---
 src/doprnt.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/doprnt.c b/src/doprnt.c
index 9316497720..841b8249c7 100644
--- a/src/doprnt.c
+++ b/src/doprnt.c
@@ -77,8 +77,7 @@
    where flags is [+ -0], width is [0-9]+, precision is .[0-9]+, and length
    is empty or l or the value of the pD or pI or PRIdMAX (sans "d") macros.
    A % that does not introduce a valid %-sequence causes undefined behavior.
-   ASCII bytes in FORMAT other than % are copied through as-is;
-   non-ASCII bytes should not appear in FORMAT.
+   Bytes in FORMAT other than % are copied through as-is.
 
    The + flag character inserts a + before any positive number, while a space
    inserts a space before any positive number; these flags only affect %d, %o,
@@ -486,14 +485,30 @@ doprnt (char *buffer, ptrdiff_t bufsize, const char *format,
 	src = uLSQM, srclen = sizeof uLSQM - 1;
       else if (EQ (quoting_style, Qcurve) && fmtchar == '\'')
 	src = uRSQM, srclen = sizeof uRSQM - 1;
-      else
+      else if (! LEADING_CODE_P (fmtchar))
 	{
 	  if (EQ (quoting_style, Qstraight) && fmtchar == '`')
 	    fmtchar = '\'';
-	  eassert (ASCII_CHAR_P (fmtchar));
+
 	  *bufptr++ = fmtchar;
 	  continue;
 	}
+      else
+        {
+          src = fmt0;
+          srclen = BYTES_BY_CHAR_HEAD (fmtchar);
+
+          /* doprnt_non_null_end doesn't know about multibyte
+             characters so can truncate format in the middle of one.
+             If that happens just ignore that character.  */
+          for ( ; *fmt != 0 && fmt < src + srclen ; fmt++);
+
+          if (fmt < src + srclen)
+            {
+              *bufptr++ = '\0';
+              break;
+            }
+        }
 
       if (bufsize < srclen)
 	{
-- 
2.26.1

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Eli Zaretskii]

> Date: Fri, 27 Nov 2020 22:24:29 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Philipp Stephani <p.stephani2@gmail.com>, 44349@debbugs.gnu.org
> 
> > I don't see why we would want to enforce that, it sounds like a grave
> > limitation.  Maybe I'm missing some background here.  The version we
> > have on emacs-27 does support non-ASCII characters in the format.
> 
> Patch attached.
> 
> I can't see any other special cases that need to be handled and all my
> tests worked, so I think this is all that's needed.

Thanks!  Can we add tests for this?

> +          /* doprnt_non_null_end doesn't know about multibyte
> +             characters so can truncate format in the middle of one.
> +             If that happens just ignore that character.  */

Is this because the buffer size is measured in characters, not bytes?
Or are there other situations where this could happen?  Can you give
an example?

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?

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third]

On Sat, Nov 28, 2020 at 09:51:57AM +0200, Eli Zaretskii wrote:
> > Date: Fri, 27 Nov 2020 22:24:29 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Philipp Stephani <p.stephani2@gmail.com>, 44349@debbugs.gnu.org
> > 
> > Patch attached.
> > 
> > I can't see any other special cases that need to be handled and all my
> > tests worked, so I think this is all that's needed.
> 
> Thanks!  Can we add tests for this?

I was wondering that. How do we add tests for internal C functions?

> > +          /* doprnt_non_null_end doesn't know about multibyte
> > +             characters so can truncate format in the middle of one.
> > +             If that happens just ignore that character.  */
> 
> Is this because the buffer size is measured in characters, not bytes?
> Or are there other situations where this could happen?  Can you give
> an example?
> 
> 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). I
suppose that's the caller's fault and it's probably not up to doprnt
to "fix" it. You would get the same effect by passing doprnt a format
string that ends "inside" a multibyte char.

This is slightly complicated by the fact that I think we want to
truncate the output on a character boundary if we run out of output
buffer, but if the format string is already truncated inside a
multibyte character then we want to output everything that's there.
Something like:

        {
          int charlen = BYTES_BY_CHAR_HEAD (fmtchar);
          src = fmt0;

          /* If the format string ends in the middle of a multibyte
             character we don't want to skip over the null byte.  */
          for (srclen = 1 ; *(src + srclen) != 0 && srclen < charlen ; srclen++);

          fmt = src + srclen;
        }

As for the old code, as far as I can see it implicitly assumed the
format string was always unibyte and do didn't do anything special if
the buffer ran out in the middle of a multibyte character, but you can
see that it took special care not to truncate a multibyte character in
the other data, e.g. a curved quote or a non-format string (doit1).
-- 
Alan Third

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

>> Thanks!  Can we add tests for this?
>
> I was wondering that. How do we add tests for internal C functions?

For src/doprnt.c, the tests go in test/src/doprnt-tests.el etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Eli Zaretskii]

> Date: Sat, 28 Nov 2020 22:06:45 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: p.stephani2@gmail.com, 44349@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?

> > 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.

Thanks.

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third]

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@idiocy.org>
> > Cc: p.stephani2@gmail.com, 44349@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

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Eli Zaretskii]

> Date: Sun, 29 Nov 2020 17:16:23 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 44349@debbugs.gnu.org, p.stephani2@gmail.com
> 
> > 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.

Anything that avoids a crash is fine in this case, thanks.

> 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.

TIA.

bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third]

unmerge 44850
close 44349 28.1
quit

On Sun, Nov 29, 2020 at 07:23:53PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 29 Nov 2020 17:16:23 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: 44349@debbugs.gnu.org, p.stephani2@gmail.com
> > 
> > > 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.
> 
> Anything that avoids a crash is fine in this case, thanks.
> 
> > 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.
> 
> TIA.

Done and pushed. Thanks.
-- 
Alan Third