Crash with "corrupted double-linked list"

[qooxzuub]

Description of the bug

When I unzip crash.zip and run python crash.py my output is:

$ python ./crash.py 
sys.version=3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]
pymupdf.version=('1.26.4', '1.26.7', None)
corrupted double-linked list
Aborted

and the exit code is 134.

The zipfile contains two small pdf files a.pdf and b.pdf, each having 6 pages, and crash.py:

import pymupdf


def crash():
    doc1 = pymupdf.open("a.pdf")
    for i in range(6):
        doc1.load_page(i).get_pixmap()
    doc2 = pymupdf.open("b.pdf")
    for i in range(6):
        doc2.load_page(i).get_pixmap()


if __name__ == '__main__':
    import sys
    print(f"sys.version={sys.version}")
    print(f"pymupdf.version={pymupdf.version}")
    crash()

How to reproduce the bug

Activate a new venv, run pip install pymupdf, unzip crash.zip and run python crash.py.

PyMuPDF version

1.26.4

Operating system

Linux

Python version

3.11

[qooxzuub]

This crash doesn't happen if you insert doc1.close() after the first for loop. Although I guess that should not be necessary?

[qooxzuub]

Valgrind output, after changing libmupdf.so.26.7 in the venv to a file compiled with debug symbols:

==13745== Memcheck, a memory error detector
==13745== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==13745== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==13745== Command: python crash.py
==13745== 
==13745== Invalid write of size 4
==13745==    at 0x67B3968: pdf_get_xref_entry_aux (pdf-xref.c:408)
==13745==    by 0x67B3B1D: pdf_get_xref_entry_no_change (pdf-xref.c:457)
==13745==    by 0x675F24E: do_objcmp (pdf-object.c:676)
==13745==    by 0x675F44F: pdf_objcmp (pdf-object.c:728)
==13745==    by 0x67A1733: pdf_cmp_key (pdf-store.c:55)
==13745==    by 0x66C41EE: fz_find_item (store.c:607)
==13745==    by 0x67A191E: pdf_find_item (pdf-store.c:100)
==13745==    by 0x67348D9: pdf_load_font (pdf-font.c:1568)
==13745==    by 0x67477D7: pdf_try_load_font (pdf-interpret.c:119)
==13745==    by 0x674ABBA: pdf_process_keyword (pdf-interpret.c:753)
==13745==    by 0x674C145: pdf_process_stream (pdf-interpret.c:1030)
==13745==    by 0x674C4CC: pdf_process_raw_contents (pdf-interpret.c:1139)
==13745==  Address 0xa796eac is 0 bytes after a block of size 60 alloc'd
==13745==    at 0x48416C4: malloc (vg_replace_malloc.c:380)
==13745==    by 0x667C630: fz_realloc_default (memory.c:253)
==13745==    by 0x667BFD6: do_scavenging_realloc (memory.c:72)
==13745==    by 0x667C2A2: fz_realloc (memory.c:147)
==13745==    by 0x67B2A75: extend_xref_index (pdf-xref.c:112)
==13745==    by 0x67B60C9: pdf_xref_find_subsection (pdf-xref.c:1241)
==13745==    by 0x67B63B1: pdf_read_old_xref (pdf-xref.c:1301)
==13745==    by 0x67B7100: pdf_read_xref (pdf-xref.c:1533)
==13745==    by 0x67B7191: read_xref_section (pdf-xref.c:1550)
==13745==    by 0x67B7493: pdf_read_xref_sections (pdf-xref.c:1625)
==13745==    by 0x67B7894: pdf_load_xref (pdf-xref.c:1731)
==13745==    by 0x67B8115: pdf_init_document (pdf-xref.c:1907)
==13745== 
sys.version=3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]
pymupdf.version=('1.26.4', '1.26.7', None)
==13745== 
==13745== HEAP SUMMARY:
==13745==     in use at exit: 2,445,090 bytes in 2,899 blocks
==13745==   total heap usage: 11,843 allocs, 8,944 frees, 50,595,974 bytes allocated
==13745== 
==13745== LEAK SUMMARY:
==13745==    definitely lost: 0 bytes in 0 blocks
==13745==    indirectly lost: 0 bytes in 0 blocks
==13745==      possibly lost: 0 bytes in 0 blocks
==13745==    still reachable: 2,445,090 bytes in 2,899 blocks
==13745==         suppressed: 0 bytes in 0 blocks
==13745== Rerun with --leak-check=full to see details of leaked memory
==13745== 
==13745== For lists of detected and suppressed errors, rerun with: -s
==13745== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)

[julian-smith-artifex-com]

Have created MuPDF bug: https://bugs.ghostscript.com/show_bug.cgi?id=708867

[julian-smith-artifex-com]

Many thanks for the detailed report, especially the valgrind output.

It's now fixed in mupdf master and 1.26.x release branch. It may be fixed in the next release of PyMuPDF, but we can't guarantee this yet because it depends on when the next mupdf release is made.