| Summary: | Seg fault applying redactions | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | Jorj <jorj.x.mckie> |
| Component: | mupdf | Assignee: | MuPDF bugs <mupdf-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | julian.smith |
| Priority: | P4 | ||
| Version: | 1.18.0 | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| Customer: | Word Size: | --- | |
| Attachments: | example: input.pdf, reproducer: myredact.c | ||
I think the problem here is that one should not call fz_drop_context() from within an active fz_try(), fz_always() or fz_catch() block - these blocks use the fz_context so it must exist until after the last block has exited. Moving the fz_drop_context() to just before the 'return EXIT_SUCCESS;' line makes the test programme work. I've added some extra text to fz_drop_context()'s comment string, to clarify things. See commit 3f80002001f. re: comment from Julian Smith I do not think this is true, because in that case: 1. the success message should have been printed 2. the output file "redacted.pdf" should have been created Neither of the two happened. Ah, that's interesting. For me, the example programme outputs 'successfully applied redactions', creates the refacted.pdf output file, and then crashes. And moving the fz_drop_context() to below the fz_catch() block fixes the crash. Could you describe what happens for you if the fz_drop_context() is moved to below the fz_catch() block? [A crash gives undefined behaviour so i'm wondering whether, on your system, the crash causes buffered output to stdout and redacted.pdf to be lost.] Thanks. Thanks for your prompt reply. I even removed dropping the context completely and still got the same behaviour (no msg, no output PDF). I am on Windows 10, compiling / linking in 64bit against 1.18.0 MuPDF from the official download site - not Github. I noticed major differences in pdf-clean.c between the two ... Apologies for the confusion; i thought i'd reproduced the bug on master, but actually that was an assert failure caused by fz_drop_context() being called from within the fz_always() block. I've now reproduced the original crash with mupdf-1.18.0 and i've confirmed that it does not occur with mupdf built from the current master. A git bisect indicates that the bug was fixed in commit 723cf4d9e9ac0 "Bug 703092: Fix logic error in structured text scanning." So i'll close this bug now. @Julian Smith Thank you very much for the information! Good to know the bug has already been resolved and will be rolled out with the next version. |
Created attachment 20478 [details] example: input.pdf, reproducer: myredact.c Segmentation fault occurs with the following example one-page PDF. C program to reproduce attached.