signal 11:SIGSEGV while using display_list.get_textpage()

[ReasunR]

Description of the bug

For the pdf (provided below), while executing get_textpage() -> got error: Process finished with exit code 139 (interrupted by signal 11:SIGSEGV)

on both macOS and docker (python:3.13.1-slim-bookworm on debian)

How to reproduce the bug

(page: fitz.Page)
display_list = page.get_displaylist(annots=False)
fz_structured_text_page = display_list.get_textpage() -> error happens here

error_file-11_anonymized.pdf

PyMuPDF version

1.26.7

Operating system

Linux

Python version

3.13

[julian-smith-artifex-com]

Thanks for the report. I've reproduced the SEGV with pymupdf-1.26.7.

However the SEGV does not occur with the recently released pymupdf-1.27.1 (the problem has presumably been fixed in mupdf) so i'll close this issue.

[mjg]

FYI: The bug still happens with mupdf 1.26.12 and current PyMuPDF. So I guess test_4907 should be run conditional on mupdf version; otoh you tie mupdf/PyMuPDF versions, so it's fine in that sense.

[julian-smith-artifex-com]

Thanks. Yes, the underlying problem (like most segv's) was in mupdf.

We run daily tests of pymupdf branch main, with mupdf branch master and mupdf release branch (currently 1.27.x). This helps ensure that we get early notification of problems that would effect future releases.

But anything else, for example older mupdf such as 1.26.12, is not tested and will likely fail some tests.

We could add specific test exclusions for older mupdf such as in this case; would that be useful to you? (I don't think we'd want to change pymupdf itself to fix problems with older mupdf, because that could get quite complicated.)

[mjg]

I just thought I'd mentioned it because PyMuPDF contains some test conditionals on mupdf versions. I build Fedora test packages in copr from PyMuPDF main branch against mupdf master branch, 1.27.x and 1.26.x, and I already skip tests based on mupdf versions, so no need to change things for me. All good, hanks :)
Once Fedora 44 is released, Fedora 42 will go EOL and with it mupdf 1.26.x and PyMuPDF 1.26.x in Fedora. I don't mix mupdf 1.26.x and PyMuPDF 1.27.x there as I don't expect them to work together, although they do most of the time.

I guess the "confusion" comes from the fact that PyMuPDF's test suite effectively is mupdf's test suite, too, and PyMuPDF has no release branches (but conditionals based in mupdf version).