Control: tags -1 + patch The crash comes from a change in MuPDF 1.25's hit_mark semantics, so it can be fixed in sioyek without downgrading mupdf.
In sioyek, pdf_viewer/pdf_renderer.cpp only starts a new search result when
hit_mark[j] == 1:
if (hit_mark[j] == 1) {
req.search_results->push_back(
SearchResult{ std::vector<fz_rect>(), i });
}
req.search_results->back().rects.push_back(
fz_rect_from_quad(hitboxes[j]));
Up to MuPDF 1.24, hit_mark is 1 on the first quad of each hit and 0 on
the rest. Since 1.25, fz_search_stext_page() wraps
fz_match_stext_page_cb() and stores the hit number instead
(oldsearch_cb: `hit_mark[data->fill] = hit;`), so the first hit is
marked 0. No result is pushed, and back() runs on an empty vector. This
matches the `!this->empty()` assertion in upstream issue #1285.
Confirmed under gdb on Ubuntu 26.04 (2.0.0+dfsg-5.1build1, mupdf
1.27.0): the SIGSEGV is in the search worker thread, immediately after
fz_search_page() and fz_rect_from_quad().
The attached patch starts a new result whenever the hit number changes
(and keeps the old check for MuPDF < 1.25). It applies on top of the
existing debian/patches series. This is not built or tested.
A quick workaround: set `super_fast_search 1` in
~/.config/sioyek/prefs_user.config. sioyek then searches its own index
and doesn't call fz_search_page().
0008-Fix-crash-on-search-with-MuPDF-1.25.patch
Description: Binary data
