Hello, The attached PDF file causes MuPDF to crash. (Now, let's see if I can attach things after posting the bug report :-)) Using the mupdf viewer to view the PDF file, I got an assert() from the MuPDF library: + mupdf/pdf_function.c:1260: loadstitchingfunc(): assert: /K too big (55) And indeed, increaing the size of MAXK fixes the issue. Thanks, Mikkel
Created attachment 4842 [details] Crashing PDF file This is the PDF file that causes the crash.
I have fix at http://github.com/kjk/mupdf/commit/fb6732b808d3e7846bfcd92fdfb082c0d2491548 Also attached for good measure. $ git diff diff --git a/mupdf/pdf_function.c b/mupdf/pdf_function.c index 42c6cd4..356a78f 100644 --- a/mupdf/pdf_function.c +++ b/mupdf/pdf_function.c @@ -1250,9 +1250,8 @@ loadstitchingfunc(pdf_function *func, pdf_xref *xref, fz_obj *dict) return fz_rethrow(error, "cannot resolve /Functions"); k = fz_arraylen(obj); - func->u.st.k = k; - pdf_logrsrc("k %d\n", func->u.st.k); + pdf_logrsrc("k %d\n", k); if (k >= MAXK) { @@ -1260,6 +1259,7 @@ loadstitchingfunc(pdf_function *func, pdf_xref *xref, fz_obj *dict) return fz_throw("assert: /K too big (%d)", k); } + func->u.st.k = k; for (i = 0; i < k; ++i) { sub = fz_arrayget(obj, i); The problem is that we set func->u.st.k even if we don't have those functions (in error case). This will cause us to try to drop null function objects, which crashes: Program received signal SIGSEGV, Segmentation fault. pdf_dropfunction (func=0x0) at mupdf/pdf_function.c:1416 1416 if (--func->refs == 0) (gdb) bt #0 pdf_dropfunction (func=0x0) at mupdf/pdf_function.c:1416 #1 0x0043db0c in pdf_loadfunction (funcp=0x22c4bc, xref=0xca6f38, ref=0xd38858) at mupdf/pdf_function.c:1427 #2 0x0044b558 in pdf_loadshadefunction (shade=0xd4fb98, xref=0xca6f38, shading=0xd31cd0, t0=0, t1=1) at mupdf/pdf_shade.c:11 #3 0x0044dc0c in pdf_loadtype3shade (shade=0xd4fb98, xref=0xca6f38, shading=0xd31cd0, ref=0xcbbec0) at mupdf/pdf_shade1.c:355 #4 0x0044bd77 in loadshadedict (shadep=0x22c6b8, xref=0xca6f38, dict=0xd31cd0, ref=0xcbbec0, matrix={a = 1, b = 0, c = 0, d = 1, e = 0, f = 0}) at mupdf/pdf_shade.c:225 #5 0x0044c08a in pdf_loadshade (shadep=0x22c6b8, xref=0xca6f38, dict=0xd31cd0, ref=0xcbbec0) at mupdf/pdf_shade.c:319 #6 0x0044b139 in pdf_loadresources (rdbp=0x22c750, xref=0xca6f38, orig=0xcbb668) at mupdf/pdf_resources.c:129 #7 0x00447043 in pdf_loadpage (pagep=0x8e390c, xref=0xca6f38, dict=0xcbb638) at mupdf/pdf_page.c:225 #8 0x004550ff in drawloadpage (pagenum=4, loadtimes=0x22cbf0) at apps/pdfdraw.c:155 #9 0x00455287 in drawpnm (pagenum=4, loadtimes=0x22cbf0, drawtimes=0x22cbd0) at apps/pdfdraw.c:216 #10 0x00455d22 in drawpages (pagelist=0x0) at apps/pdfdraw.c:402 #11 0x00456027 in main (argc=3, argv=0xca2520) at apps/pdfdraw.c:481 Alternatively, pdf_dropfunction() could just ignore null func. Also, MAXK = 32 (in pdf_function.c) seems a bit restrictive. I've seen a PDF with k being 255, so increasing this to at least 256 would be nice. Alternatively, if size of objects is an issue, the code could dynamically allocate arrays that depend on MAX, instead of putting stuff inline.
Created attachment 4871 [details] Patch for the crash
Made stitching functions be dynamically allocated.