Created attachment 19963 [details] mupdf-x11 stack trace from within gdb mupdf-x11 runs without problems on the Solaris 10 i86pc platform, but consistently crashes on Solaris 10 sparc. Per dialog with and instruction by sebras on the #mupdf IRC channel, I'm including the test PDF file which contains no graphics (although the application crashes with any PDF file) and the stack trace of the crash. mupdf-x11 has been compiled both 32- and 64-bit; in both cases it crashes in the same way. Compiler: GCC 9.2.0.
Created attachment 19964 [details] Test PDF document which only contains text
When debugging the code in gdb(1), the crash occurs in: fz_keep_path at source/fitz/path.c:101; Specifically, it will eventually crash at this expression: if (path->refs == 1 && path->packed == FZ_PATH_UNPACKED) when this occurs, both path->refs and path->packed are 1. The instruction where the crash occurs is: ldx [ %i1 ], %g4 and %i1 contains an even, 32-bit hexadecimal number, presumably an address.
The https://git.ghostscript.com/?p=user/robin/mupdf.git;a=patch;h=235f70d41043b82c3a66de977faca79c4c0791f4 patch mostly applies, although it has a couple of errors: > gpatch -uNp1 < sparc-jumbo.patch patching file source/fitz/path.c Hunk #3 succeeded at 77 (offset -13 lines). Hunk #5 FAILED at 165. Hunk #6 FAILED at 180. Hunk #7 succeeded at 171 (offset -30 lines). Hunk #9 succeeded at 219 (offset -30 lines). Hunk #11 succeeded at 304 (offset -30 lines). Hunk #13 succeeded at 412 (offset -30 lines). Hunk #15 succeeded at 483 (offset -30 lines). Hunk #17 succeeded at 585 (offset -30 lines). Hunk #19 succeeded at 972 (offset -30 lines). Hunk #21 succeeded at 1483 (offset -30 lines). 2 out of 21 hunks FAILED -- saving rejects to file source/fitz/path.c.rej unfortunately it doesn't build out of the box just yet: > gmake CC=gcc CXX=g++ CC build/release/source/fitz/path.o source/fitz/path.c: In function 'fz_pack_path': source/fitz/path.c:158:10: error: 'fz_path' {aka 'const struct fz_path'} has no member named 'packed' 158 | if (path->packed) | ^~ gmake: *** [Makefile:101: build/release/source/fitz/path.o] Error 1
I believe (hope!) that this commit will fix your problems: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=2acd839e73a2686008dabf3b350d87d639359fb5 If that doesn't solve it, maybe try this one too: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=e3c3cbe71bbee2762d6cbc4d0c1c96051bab1eb6 but, hopefully, the need for the second should have vanished with the first one.
Apologies. Better fix is: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=d0c52a75dee4f6b3677003de05f11ad9608bce64 I'm working with the current head, so basically 1.18.0.
Applying https://git.ghostscript.com/?p=user/robin/mupdf.git;a=patch;h=d0c52a75dee4f6b3677003de05f11ad9608bce64 makes the 64-bit build work. The 32-bit version however crashes, producing the following stack trace in the process: > mdb core Loading modules: [ libc.so.1 ld.so.1 ] > $c cmsSetAdaptationState+0x34(24d02f8, bff00000, 0, 24d1d78, 401a, 1) cmsCreateMultiprofileTransform+0x78(24d02f8, ffbfcd38, 2, 300a, 401a, 1) cmsCreateTransform+0x30(24d02f8, 24d0e88, 300a, 24d1d78, 401a, 1) fz_new_icc_link+0x364(401a, 24d1cc0, 300a, 24d3420, 0, 0) fz_find_icc_link+0x1e0(0, 0, 0, 1, 2495210, 0) fz_init_process_color_converter.isra.0+0x1b0(2495210, ffbfd024, ffbfd03c, 1, 1, 0) fz_find_color_converter+0x84(0, ffbfd024, 24d1cc0, 24d3420, 0, ffbfd018) fz_convert_color+0x40(2495210, 24d1cc0, ffbfd328, 24d3420, ffbfd0d4, 0) fz_stext_fill_text+0x70(2495210, 2657108, 2635820, ffbfd168, 24d1cc0, ffbfd328) fz_fill_text+0xf4(bf800000, c2740000, 4436c000, 1, 1, 0) fz_run_display_list+0xef0(c2740000, 4436c000, 0, 0, c2740000, 4436c000) pdfapp_showpage+0x9f8(3f800000, bf800000, 0, 0, 2479390, 485c) pdfapp_open_progressive+0x330(2479390, ffbffb08, ffffdc00, 0, 245ab58, 2479390) main+0x630(2479364, 780, 0, 4b0, 2479390, 248e0c8) _start+0x5c(0, 0, 0, 0, 0, 0) however, the 32-bit version mupdf-x11 does not crash when a PDF without graphics is provided as an argument.
The error you're getting now is from lcms2. lcms2 was updated between 1.17.0 and 1.18.0. So I fear, we really need you to try it with the new version. Thanks for all your efforts so far.
After building 1.18.0 with the above patch: - 32-bit mupdf-x11 still crashes rendering a PDF document with graphics; - the stack trace of the 32-bit core dump appears unchanged from before; - 32-bit mupdf-x11 will render a simple PDF document without graphics; - 64-bit mupdf-x11 now renders a PDF document with graphics. 64-bit mupdf-gl's behavior is unchanged: > ./mupdf-gl RESOURCE.PDF Bus error (core dumped) > mdb core Loading modules: [ libc.so.1 ld.so.1 ] > ::status debugging core file of mupdf-gl (64-bit) from hostname.subdomain.domain.tld file: ./mupdf-gl initial argv: ./mupdf-gl RESOURCE.PDF threading model: multi-threaded status: process terminated by SIGBUS (Bus Error) > $c libX11.so.4`_XData32+0xa8(1027098d0, 4, 0, 102710d54, 0, ffffffff7ffff254) libX11.so.4`XChangeProperty+0x3b8(1027098d0, 3fffff, 6, 6, 102710d3c, ffffffff7ffff254) fgPlatformOpenWindow+0x484(102867f10, 102645338, 0, ffffffff00000000, ffffffffffffffff, ffffffff7ffff430) fgOpenWindow+0x38(102867f10, 1004325f8, 0, ffffffffffffffff, ffffffffffffffff, 0) fgCreateWindow+0x120(102867f10, 1004325f8, 0, ffffffffffffffff, ffffffffffffffff, 1) glutCreateWindow+0x58(1004325f8, 32d, ffffffff7ffffa10, 0, 1025e3eb8, 102614f18) ui_init+0x50(23d, 32d, 1004325f8, 10269c520, 10269c548, 10269c560) main+0x3d4(2, ffffffff7ffff9f8, ffffffff7ffffa10, 0, 1025e3eb8, 1025e3eb8) _start+0x7c(0, 0, 0, 0, 0, 0) >
The fix for the displaylist alignment problems on sparc has gone in: commit bb1cb69d1cd2d87137b153dfd12e4c787fb545a7 Author: Robin Watts <Robin.Watts@artifex.com> Date: Mon Oct 19 18:35:05 2020 +0100 Bug 703004: Attempt to fix sparc data alignment problems. DisplayList shows crashes on sparc due to sparcs data alignment requirements. This fixes that, but we may still have some problems elsewhere that need fixing in a followup.
#0 0x003289ec in cmsSetAdaptationState (ContextID=0x254e6d0, d=-1) at thirdparty/lcms2/src/cmsxform.c:67 #1 0x0032a3b4 in cmsCreateMultiprofileTransform (ContextID=0x254e6d0, hProfiles=0xffbfd5c0, nProfiles=2, InputFormat=12298, OutputFormat=16410, Intent=1, dwFlags=10240) at thirdparty/lcms2/src/cmsxform.c:1523 #2 0x0032a47c in cmsCreateTransform (ContextID=0x254e6d0, Input=0x254f260, InputFormat=12298, Output=0x2550150, OutputFormat=16410, Intent=1, dwFlags=<optimized out>) at thirdparty/lcms2/src/cmsxform.c:1546 #3 0x0020a24c in fz_new_icc_link (ctx=<optimized out>, src=0x2550098, src_extras=<optimized out>, dst=0x25517f8, dst_extras=<optimized out>, prf=<optimized out>, rend=..., format=<optimized out>, copy_spots=<optimized out>) at source/fitz/color-lcms.c:256 #4 0x000e86f0 in fz_find_icc_link (ctx=<optimized out>, src=<optimized out>, src_extras=0, dst=<optimized out>, dst_extras=<optimized out>, prf=<optimized out>, rend=..., format=<optimized out>, copy_spots=<optimized out>) at source/fitz/colorspace.c:818 #5 0x000e895c in fz_init_process_color_converter (ctx=0x25135e8, ss=<optimized out>, ds=<optimized out>, is=<optimized out>, params=..., cc=<optimized out>, cc=<optimized out>) at source/fitz/colorspace.c:908 #6 0x000e8a44 in fz_find_color_converter (ctx=<optimized out>, cc=0xffbfd8ac, ss=0x2550098, ds=0x25517f8, is=0x0, params=...) at source/fitz/colorspace.c:958 #7 0x000e8ba8 in fz_convert_color (ctx=0x25135e8, ss=0x2550098, sv=0xffbfdd98, ds=0x25517f8, dv=0xffbfd940, is=0x0, params=...) at source/fitz/colorspace.c:978 #8 0x000fa830 in resolve_color (ctx=0x25135e8, op=<optimized out>, color=0xffbfdd98, colorspace=0x2550098, alpha=1, color_params=..., colorbv=<optimized out>, dest=<optimized out>) at source/fitz/draw-device.c:531 #9 0x000fe328 in fz_draw_fill_text (ctx=0x25135e8, devp=0x25bb2a0, text=0x25d1d80, in_ctm=..., colorspace_in=<optimized out>, color=<optimized out>, alpha=<optimized out>, color_params=...) at source/fitz/draw-device.c:995
The latest proposed fix for this is: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=eaa20f4e9f9a7dcca1d3d1cc7f27736b8e092416
The proposed fix was comitted to master a long time ago as the commit below. Did this fix the problem you reported or is 32-bit graphics still causing problems? commit e74051c21ee5a6dbf891e30ef315b96bb65eb4e2 Author: Robin Watts <Robin.Watts@artifex.com> Date: Mon Oct 19 18:35:05 2020 +0100 Bug 703004: Attempt to fix sparc data alignment problems. DisplayList shows crashes on sparc due to sparcs data alignment requirements. This fixes that, but we may still have some problems elsewhere that need fixing in a followup.
In the absence of a confirmation I'm going to assume that the committed fix resolved the reported problem, if not user38 will have to reopen the bug report.