Segfault when Pdfium compiled with v8/xfa

[benwr]

Hello! Merry Christmas, and thanks for this awesome tool!

The library works great if I use a (static or dynamic) pdfium build without v8/XFA support, but when I use a library with XFA support (I've tried multiple version numbers; static and dynamic; e.g. it happens with the pdfium-binaries' v8 lib), I get a segfault. It appears to happen when a PdfDocument is dropped, so my temporary workaround is to just... not drop any PdfDocuments until my program exits.

[ajrcarey]

Hi @benwr , thank you for reporting the issue. Can you please provide the exact Pdfium build and version you are using (ideally with a link), your platform details, and a minimal code sample that demonstrates the problem, so I can try to reproduce it here.

Possibly related to bblanchon/pdfium-binaries#105, although that's just a guess at this stage. If so, then the problem is most likely in pdfium-render's initialisation of the document's form fill environment, which currently does not set a valid Javascript execution environment.

Just out of interest, can you explain your use case? I'm curious why you need a Javascript execution environment, and how you were planning on utilising it (since pdfium-render doesn't expose any interface to access it).

[benwr]

Sure - As I mentioned I've tried with several recent builds. The easiest to demonstrate is the most recent pdfium-binaries M1 V8 build (pdfium-v8-mac-arm64.tgz on this release page (i.e. PDFium 122.0.6205.0, at least as the page claims). I've also tested building several dynamic and static versions of the pdfium upstream, building from main and from recent tagged commits; I seem to get the same issue.

Here's a repo containing a minimal reproduction for me, including the .dylib from the above release:

https://github.com/benwr/pdfium_segfault

(cargo run -- example.pdf from the project root gives a segfault; note git-lfs is probably required to properly clone, though)

As you can see in the code, I think I need to render a page for the segfault to trigger.

My use case is rendering tax forms from diverse origins to a consistent image format. Some of the forms I need to render rely on XFA, which requires v8. If pdfium-render doesn't actually render XFA form content, then I suppose I won't actually be able to use it in the way I was hoping to.

[benwr]

(My workaround of "spawn a subprocess to render the page, and then in that subprocess use std::process::exit to avoid calling any destructors" seems to be working fine, so this bug isn't a major priority for me personally)

[ajrcarey]

Many thanks. Your use case makes sense. While pdfium-render doesn't expose any XFA-related functionality itself, the rendering is handled by Pdfium directly - so as long as Pdfium can render the XFA content in your source documents, you should be fine. (Your work-around approach may already have given you a sense of whether the rendering is working as expected.)

I am unable to reproduce the problem on Arch Linux x64 using your repo, sample document, and the equivalent pdfium-binaries release for linux-x64. This may suggest the problem is specific to macOS, possibly to the M1 silicon build. I do have an M1 mac sitting around here, let me see if I can reproduce the problem there.

[ajrcarey]

Ok, I can now reproduce the problem. It's caused by FPDF_CloseDocument() being called before the document's form is released by calling FPDFDoc_ExitFormFillEnvironment(). The order in which these functions are called doesn't seem to matter when using a non-V8/XFA build of Pdfium, but clearly does matter when using a V8/XFA build. I have pushed a tiny patch that ensures FPDFDoc_ExitFormFillEnvironment() is reliably called before FPDF_CloseDocument(); with this patch, your sample code now completes without failure.

You can test this patch by taking pdfium-render as a git dependency in your Cargo.toml.

At a casual glance, the rendering output of your sample document looks the same to my untrained eye as the rendering of Adobe Acrobat Reader.

[benwr]

Great, thanks for the quick fix!

[ajrcarey]

Updated README. Fix will be released in crate version 0.8.17.