"Sean Whitton" <spwhitton@spwhitton.name> writes:

> X-debbugs-cc: notmuch@notmuchmail.org
>
> In 'emacs -q', after 'M-x load-library RET notmuch RET' (version 0.39)
> and with a populated notmuch database, evaluating the following form
> crashes Emacs and manages to bring down the entire Wayland compositor
> and systemd user session:
>
>     (notmuch-search "thread:00000000000a162e thread:00000000000a162e ...")
>
> where "..." is the same space-separated thread:00000000000a162e repeated
> until the query is around 2000 characters in length.

What's your font width (for the font used by sway)? My assumption is
that sway is trying to create a cairo_image_surface displaying that
string, which ends up being wider than 32767 (= MAX_IMAGE_SIZE) pixels,
and sway fails to properly handle the error:

> I think this is a display engine problem.
> This is my Wayland error output:
>
> 00:04:33.890 [ERROR] [sway/sway_text_node.c:110] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
> 00:04:33.890 [ERROR] [sway/sway_text_node.c:110] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
> sway: render/pass.c:23: wlr_render_pass_add_texture: Assertion `box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height' failed.
>  err: wayland.c:1617: failed to read events from the Wayland socket: Broken pipe

> There has to be an Emacs bug here because Lisp should not be able to
> crash Emacs like this.  Reproducible with and without native compilation
> enabled, and with Emacs 30.

I agree that Emacs should not pass overly long strings to the window
manager (equivalent), but the "window manager" shouldn't crash the
entire Wayland session because of an overly long string provided by an
application, either.

Do we know where the string is passed from Emacs, so we could truncate
it, and what a reasonable limit would be?

My guess is this is 'pgtk_set_name_internal' in pgtkfns.c, and I'd
suggest a limit of 512 characters. Would you be able to test a patch to
this effect?

Pip

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org