fix(pdfium): don't double-free the buffer when PDFium refuses a document

[mikepenz]

The bug

openPdfDocument frees the native buffer twice when PDFium refuses to open the bytes — once in the h == 0L branch, then again in the enclosing catch, which the error(...) on the very next line always reaches:

val bufferAddr = PdfiumBridge.nAllocBuffer(bytes)
try {
    …
    if (h == 0L) {
        for (j in 0 until i) PdfiumBridge.nCloseDocument(handles[j])
        PdfiumBridge.nFreeBuffer(bufferAddr)   // free #1
        error("PDFium refused to open document (…)")
    }
    …
} catch (t: Throwable) {
    PdfiumBridge.nFreeBuffer(bufferAddr)       // free #2 — same address
    throw t
}

Any bytes PDFium rejects hit it: a 401/404 HTML body served in place of the file, the wrong variant of an attachment, a corrupt or truncated download. The app doesn't get an exception — the process dies.

Android:

pid: 12746, tid: 12918, name: pdfium-shared  >>> com.example.app <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'Scudo ERROR: invalid chunk state when deallocating address 0x20000778eedb3c0'
  #05 scudo::Allocator<scudo::AndroidNormalConfig, …>::deallocate(void*, …)
  #06 art_quick_generic_jni_trampoline
  #08 dev.nucleusframework.pdfium.PdfDocument_androidKt$openPdfDocument$2.invokeSuspend

Desktop/JVM is affected identically (PdfDocument.jvm.kt has the same shape) and exits 134.

This isn't defensible from the caller's side: PdfReaderState.open already wraps the call in catch (Throwable), but the double free happens below the JNI boundary, so there is nothing to catch. Validating bytes before calling is only a partial workaround — it can't cover encrypted or subtly corrupt PDFs that PDFium alone can decide on.

The fix

Drop the inner nFreeBuffer; the catch already owns the buffer. Document handles opened before the failure are still closed in the branch, unchanged.

androidMain + jvmMain only — iosMain pins/unpins the ByteArray and webMain transfers an ArrayBuffer, so neither has a second free.

Test

Adds pdfium/src/jvmTest/ — the first test source set in the repo, so :pdfium:check (already run by Pre Merge Checks, no workflow change needed) now covers the JNI open path.

• refusedBytesThrowInsteadOfAbortingTheProcess — on the parent commit this does not fail, it takes the test JVM down (finished with non-zero exit value 134 … SIGABRT). Reaching the assertion at all is the signal.
• aValidDocumentStillOpens — keeps the success path's single free exercised.

Verified both directions locally on darwin-aarch64:

	:pdfium:jvmTest
with the fix	BUILD SUCCESSFUL
fix reverted, test kept	BUILD FAILED — Gradle Test Executor 2 finished with non-zero exit value 134

One line of wiring: jvmTest.dependencies { implementation(libs.kotlin.test) } (libs.kotlin.test was already in the catalog).

The four configureCMakeDebug[<abi>] tasks fail on my machine for want of an NDK/CMake toolchain, unrelated to this change; CI has them.

[mikepenz]

Feel free to replace this with a different PDF test file that you control.

[Copilot]

Pull request overview

Fixes a native crash in openPdfDocument (Android + JVM) caused by freeing the same native buffer twice when PDFium rejects input bytes, and adds a JVM regression test to ensure the failure path throws rather than aborting the process.

Changes:

• Remove the redundant nFreeBuffer(bufferAddr) in the h == 0L failure branch on Android and JVM.
• Add jvmTest coverage for both the refused-bytes path and a minimal valid PDF success path.
• Wire kotlin.test into the jvmTest source set dependencies.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
pdfium/src/jvmMain/kotlin/dev/nucleusframework/pdfium/PdfDocument.jvm.kt	Stops double-free on open failure (JVM actual).
pdfium/src/androidMain/kotlin/dev/nucleusframework/pdfium/PdfDocument.android.kt	Stops double-free on open failure (Android actual).
pdfium/src/jvmTest/kotlin/dev/nucleusframework/pdfium/OpenPdfDocumentTest.kt	Adds regression + success-path tests for JVM open.
pdfium/build.gradle.kts	Adds kotlin.test dependency for jvmTest.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.