Errors using FPDF_LoadXFA in v8 build

[jerbob92]

Hi there,

I'm currently implementing XFA support into go-pdfium. I often get errors in my unit tests when executing FPDF_LoadXFA (but not always). The error is:

#
# Fatal error in v8::ToLocalChecked
# Empty MaybeLocal
#

When I put a time.Sleep between FPDFDOC_InitFormFillEnvironment and FPDF_LoadXFA I get a different error, but it always seems to happen (without the time.Sleep, it sometimes succeeds):

#
# Fatal error in , line 0
# Check failed: IsCreationThread().
#
#
#
#FailureMessage Object: 0x7ff472ffc980
==== C stack trace ===============================

    /opt/lib/pdfium/lib/libpdfium.so(+0x170ccf3) [0x7ff4ee634cf3]
    /opt/lib/pdfium/lib/libpdfium.so(+0x1710b2b) [0x7ff4ee638b2b]
    /opt/lib/pdfium/lib/libpdfium.so(+0x17033ef) [0x7ff4ee62b3ef]
    /opt/lib/pdfium/lib/libpdfium.so(+0xfe5035) [0x7ff4edf0d035]
    /opt/lib/pdfium/lib/libpdfium.so(+0x787f7a) [0x7ff4ed6aff7a]
    /opt/lib/pdfium/lib/libpdfium.so(+0x787d4b) [0x7ff4ed6afd4b]
    /opt/lib/pdfium/lib/libpdfium.so(+0x7e177b) [0x7ff4ed70977b]
    /opt/lib/pdfium/lib/libpdfium.so(+0x7b39b6) [0x7ff4ed6db9b6]
    /opt/lib/pdfium/lib/libpdfium.so(FPDF_LoadXFA+0x24) [0x7ff4ed66bfe4]

I noticed that you patch in the loading of v8, so I was wondering if the issue could be somewhere in there.

The issue could be very well in my own code and the handling of pointers, where possibly something is garbage collected where it shouldn't, but I wanted to check with you first, since I didn't have issues with FPDFDOC_InitFormFillEnvironment before, and that also uses the same pointer logic.

[bblanchon]

Hi @jerbob92!

Did you see https://github.com/bblanchon/pdfium-binaries/issues/105#issuecomment-1676016471 and https://github.com/bblanchon/pdfium-binaries/issues/105#issuecomment-1733139590?

[jerbob92]

@bblanchon Yep, I follow all those rules, and sometimes the tests pass, sometimes they don't, so I don't think it's related to that.

However, I also posted to the pdfium forum for something else and their reply doesn't give too much confidence: https://groups.google.com/g/pdfium/c/kYdZ7Qa9fO8/m/IFqp47OBAwAJ So I might just let it go for now...

[mara004]

FWIW, FPDF_LoadXFA() seems to work well with pypdfium2, so I guess it might be an issue in your project rather than pdfium or pdfium-binaries.

---

You can check yourself by installing pypdfium2 like this:

PDFIUM_PLATFORM=auto-v8 pip install -v pypdfium2 --no-binary pypdfium2

and use pypdfium2 render ... on an XFA PDF.

[jerbob92]

Thanks @mara004, I have tested some more and the issue was caused by something seemingly completely unrelated, to check whether the rendering works properly, I create a bitmap with FPDFBitmap_CreateEx so that I can draw to Go image pixels directly. This has always worked perfectly fine, but for some reason this causes issues with V8. I now use FPDFBitmap_Create and FPDFBitmap_GetBuffer, and the issue is gone.

I have to look into it later to see if I'm actually doing something wrong, but I used FPDFBitmap_CreateEx the same way I used it everywhere else and it never gives issues.

Edit: celebrated too soon, it's actually still there, just less.

According to a pdfium maintainer:

The XFA support in PDFium today is essentially unfinished. Common XFA forms in the wild do not work. As far as I'm aware, no resources are being put into finishing XFA support.

So I don't think I will put much more time into it, as it basically means the v8/XFA support is a bit useless?

[mara004]

Hmm, I'm not much into XFA, but leastways there are PDFs where it does work. In any case, I never had random crashes with XFA yet. If there's a bug in pdfium, I'd have expect it to crash immediately during an API call on a specific PDF rather than randomly at runtime, or even to cleanly report failure instead of crashing. These symptoms still tend to remind me more of caller-side object lifetime issues, which I remember well from the early days of pypdfium2.

[bblanchon]

So I don't think I will put much more time into it, as it basically means the v8/XFA support is a bit useless?

I never had to use v8 or XFA in my projects; I added it to the build because @TcT2k wrote a PR.

[jerbob92]

In any case, I never had random crashes with XFA yet. If there's a bug in pdfium, I'd have expect it to crash immediately during an API call on a specific PDF rather than randomly at runtime, or even to cleanly report failure instead of crashing. These symptoms still tend to remind me more of caller-side object lifetime issues, which I remember well from the early days of pypdfium2.

I would agree but I didn't change anything to how I interact with pdfium, or the order of executing, I also checked If I do everything in the correct order. The errors seem to come from the v8 part of the codebase as well.

Currently I can render the image just fine if it's outside the tests, but when it's inside the tests it still fails often (I use 1 pdfium instance for all the tests). I will try to make my own v8 debug build to see if I can get more details in the crash.

I never had to use v8 or XFA in my projects; I added it to the build because @TcT2k wrote a PR.

Yeah me neither, I only looked into it due to a user request: https://github.com/klippa-app/go-pdfium/issues/156 And now he's not replying anymore :crying_cat_face:

[TcT2k]

So I don't think I will put much more time into it, as it basically means the v8/XFA support is a bit useless?

I never had to use v8 or XFA in my projects; I added it to the build because @TcT2k wrote a PR.

Sorry for the late reply:

At the time it was useful for my wxPDFView wrapper, to support PDF forms (which were requested by customers). I'm currently not using PDFium anymore as it became to cumbersome to maintain, even with the excellent work on the binaries you provide.

[jerbob92]

Still trying to figure this out, the issue seems to be caused by the v8 garbage collection being ran from another thread, when using a pdfium debug build I get the following error:

# Fatal error in ../v8/src/heap/cppgc/prefinalizer-handler.cc, line 59
# Debug check failed: CurrentThreadIsCreationThread().

Since I don't have control over threads I'm wondering how I would be able to cause this...