Subject: segfault when using get_text() on arm64

From: Johannes Schauer Marin Rodrigues <[email-masked]>
Date: Tue, 18 Mar 2025 07:05:50 +0100

Package: python3-pymupdf
Version: 1.25.0+ds1-2
Severity: serious

Hi,

the autopkgtest of pymupdf currently segfaults on arm64, ppc64el and
riscv64. In an attempt to get to the bottom of this I found a minimal
reproducer:

python3 -c "import pymupdf,sys; doc=pymupdf,sys; doc=pymupdf.open(sys.argv[1]);doc[0].get_text()" /usr/share/doc/fig2dev/manual.pdf

Which pdf document is opened seems to be irrelevant. It crashed for any that I
tried. This makes this bug RC, I think.

I can reproduce the problem in a minimal Debian unstable chroot:

mmdebstrap --include=python3-pymupdf,python3-pymupdf-dbgsym,libmupdf25.1-dbgsym,gdb,fig2dev --customize-hook='env SHELL=/bin/sh chroot "$1" gdb -batch -ex "set logging enabled on" -ex "set pagination off" -ex run -ex "bt full" -ex quit --args python3 -c "import pymupdf,sys; doc=pymupdf,sys; doc=pymupdf.open(sys.argv[1]);doc[0].get_text()" /usr/share/doc/fig2dev/manual.pdf' unstable /dev/null http://deb.debian.org/debian "deb http://deb.debian.org/debian-debug unstable-debug main"
[...]
Program received signal SIGSEGV, Segmentation fault.
0x0000fffff2d13ce8 in mupdf::FzStextPageIterator::FzStextPageIterator (this=0xfffff74b5e6c, item=...) at platform/c++/implementation/classes.cpp:22939
warning: 22939	platform/c++/implementation/classes.cpp: No such file or directory
#0  0x0000fffff2d13ce8 in mupdf::FzStextPageIterator::FzStextPageIterator (this=0xfffff74b5e6c, item=...) at platform/c++/implementation/classes.cpp:22939
No locals.
#1  0x0000fffff2d13d3c in mupdf::FzStextPage::begin (this=this@entry=0x11dd690) at platform/c++/implementation/classes.cpp:22868
        ret = {m_item = {m_internal = 0x6665727800000000, static s_num_instances = 1}}
#2  0x0000fffff74ad020 in JM_print_stext_page_as_text (res=..., page=...) at ./src/build/extra.i.cpp:5570
        block = {m_internal = 0xfffff7fe6420}
        __for_range = @0x11dd690: {m_internal = 0x1196ea8}
        __for_begin = {m_item = {m_internal = 0xfffff7fe6430}}
        __for_end = {m_item = {m_internal = 0xffffffffe7c0}}
        rect = {x0 = <optimized out>, y0 = 0, x1 = <optimized out>, y1 = 792}
#3  0x0000fffff74ad320 in _wrap_JM_print_stext_page_as_text (self=<optimized out>, args=<optimized out>) at ./src/build/extra.i.cpp:10767
        fail = <optimized out>
        resultobj = 0x0
        arg1 = 0x11dd560
        arg2 = <optimized out>
        argp1 = 0x11dd560
        res1 = <optimized out>
        argp2 = 0x11dd690
        res2 = <optimized out>
        swig_obj = {0xfffff196af90, 0xfffff196b380}
#4  0x00000000004e924c in ?? ()
No symbol table info available.
#5  0x00000000004a3dc0 in _PyObject_MakeTpCall ()
No symbol table info available.
#6  0x00000000004c1fd4 in _PyEval_EvalFrameDefault ()
No symbol table info available.
#7  0x00000000005d2040 in PyEval_EvalCode ()
No symbol table info available.
#8  0x00000000005fd91c in ?? ()
No symbol table info available.
#9  0x00000000005f7e70 in ?? ()
No symbol table info available.
#10 0x00000000005e6094 in ?? ()
No symbol table info available.
#11 0x00000000005e5e1c in ?? ()
No symbol table info available.
#12 0x00000000006229f8 in Py_RunMain ()
No symbol table info available.
#13 0x00000000005bc188 in Py_BytesMain ()
No symbol table info available.
#14 0x0000fffff7ce229c in ?? () from /lib/aarch64-linux-gnu/libc.so.6
No symbol table info available.
#15 0x0000fffff7ce237c in __libc_start_main () from /lib/aarch64-linux-gnu/libc.so.6
No symbol table info available.
#16 0x00000000005badb0 in _start ()
No symbol table info available.
A debugging session is active.

	Inferior 1 [process 4068] will be killed.

Any idea what could be going on?

Thanks!

cheers, josch

---

From: Johannes Schauer Marin Rodrigues <[email-masked]>
Date: Mon, 21 Apr 2025 19:06:13 +0200

Control: reassign -1 mupdf 1.25.1+ds1-5
Control: tag -1 + patch

Hello mupdf and pymupdf maintainers,

my package plakativ is not in testing because of an RC bug in pymupdf. 
It turns out that to fix #1100748, src:mupdf has to be changed like 
this:

--- a/debian/rules
+++ b/debian/rules
@@ -36,7 +36,7 @@ else
      CFLAGS += -O2
  endif

-BUILD_FLAGS = build=debug shared=yes OS=Linux XCFLAGS="$(CFLAGS)" 
XLDFLAGS="$(LDFLAGS)"
+BUILD_FLAGS = build=debug shared=yes OS=Linux XCFLAGS="$(CFLAGS)" 
XLDFLAGS="$(LDFLAGS)" XCXXFLAGS="-DNDEBUG"
  BUILD_FLAGS += LINUX_OR_OPENBSD=yes
  # Force using system library
  BUILD_FLAGS += USE_SYSTEM_MUJS=yes

For details, please see the comments of Julian Smith: 
https://github.com/pymupdf/PyMuPDF/issues/4390

mupdf maintainers: could you take care of uploading a new version of 
src:mupdf with above change? If you don't have time, I can offer to NMU 
src:mupdf for you.

As far as my testing goes, pymupdf seems to work fine even without being 
rebuilt. I wonder if we should schedule a binNMU after the src:mupdf 
fix. Bastian, what do you think?

I brought up this topic in #debian-release today and Sebastian Ramacher 
said that since pymupdf is in Bookworm, this would be eligible for an 
exception. Bastian, do you want to file the pre-approval bug or would 
you like me to take care of it?

Thanks!

cheers, josch

P.S.: currently on vacation and hence sending without PGP signature, 
sorry

---

From: Daniel Echeverri <[email-masked]>
Date: Mon, 21 Apr 2025 13:52:37 -0500

Hello Josch!

> P.S.: currently on vacation and hence sending without PGP signature,

Thanks for your report and the patch!  I will work on it tonight.

Regards!

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB