| Summary: | source/fitz/colorspace.c:1399: fast_rgb_to_cmyk: Assertion `"This should never happen" == NULL' failed. | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | Koz Ross <koz.ross> |
| Component: | mupdf | Assignee: | MuPDF bugs <mupdf-bugs> |
| Status: | RESOLVED INVALID | ||
| Severity: | major | CC: | bugmenot, gentoolinux, koz.ross, sebastian.rasmussen |
| Priority: | P4 | ||
| Version: | 1.12.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
|
Description
Koz Ross
2018-04-19 12:57:25 UTC
> mupdf-x11: source/fitz/colorspace.c:1486: fast_rgb_to_cmyk: Assertion `"This should never happen" == NULL' failed. Confirming. Still an issue in mupdf-1.13.0. Another example PDF that triggers it 100% of the time: https://udextension.s3.amazonaws.com/factsheet/wp-content/uploads/2012/10/Cover-crops-fact-sheet.pdf Last good: app-text/mupdf-1.11-r2 I just compiled 1.13.0 from source and attempted to reproduce the issue with Cover-crops-fact-sheet.pdf, but I was unsuccessful. I compiled the 1.13.0 debug variant using gcc 7.3.0-25 and clang4.0.1-10+b1 (what I happend to have on Debian/testing). I ran both using ASAN and valgrind. I also compiled the 1.12.0 debug variant using gcc and clang, running both using ASAN and valgrind. I can't reproduce the issue. Note I only compiled for 64 bit because I'm on a 64 bit system. I ran the following commands: make -j4 build=debug valgrind ./build/debug/mutool draw -s t ./Cover-crops-fact-sheet.pdf make -j4 build=sanitize ./build/sanitize/mutool draw -s t ./Cover-crops-fact-sheet.pdf make -j4 nuke make -j4 CC=clang LD=clang build=debug valgrind ./build/debug/mutool draw -s t ./Cover-crops-fact-sheet.pdf make -j4 CC=clang LD=clang build=sanitize ./build/sanitize/mutool draw -s t ./Cover-crops-fact-sheet.pdf Next I looked at: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/mupdf/mupdf-1.12.0.ebuild Judging by I think the mupdf-gl/mupdf-x11 you are using is linked to the system lcms instead of the lcms2 that we provide in our source tree? If so I think the system lcms might be lacking some features that we require and thus provide in the lcms2 we bundle. Perhaps you can verify this by running "ldd /usr/bin/mupdf-x11" and/or "ldd /usr/bin/mupdf-gl". If this is the case would you mind cloning the source and building it from the source tree and trying that version? If that resolves your issue we do have some indication of what might be the reason. I am also hitting the bug with MuPDF 1.1[23].0 on Gentoo Linux. Compiling mupdf with USE="lcms" solves the problem. If the lcms USE flag is set, the thirdparty lib lcms2 is built. By default, i.e. without USE flag lcms set, the directory thirdparty/lcms2 is removed and no thirdparty libs are built (see https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/mupdf/mupdf-1.13.0-r1.ebuild). So lcms2 is the root cause (see also https://bugzilla.redhat.com/show_bug.cgi?id=1553915#c7). If I correctly understand what you, you agree that this was due to the differences between the bundled lcms2 library version and your system version of lcms2. So I close this bug at the moment. Should my assessment be wrong, please reopen the bug. |