PdfInvalidFormatException occurs for some PDF files when using PDFtoImage 5.2.0 on Ubuntu 22.04

[vsolominov]

PDFtoImage version

5.2.0

OS

Linux

OS version

Ubuntu 22.04

Architecture

x64

Framework

.NET (Core)

App framework

Console App

Detailed bug report

Problem

I am using the PDFtoImage NuGet package version 5.2.0 to extract images from PDF files on Ubuntu 22.04. Some PDFs are processed correctly, but on certain PDFs I get the following exception:

PDFtoImage.Exceptions.PdfInvalidFormatException: File not in PDF format or corrupted.

Interestingly, if I limit the application to process only one or two PDFs per run, all files are processed correctly. The issue consistently occurs when processing the third file in the same run.

Code to Reproduce

internal class Program
{
    private static async Task Main(string[] args)
    {
        foreach (var file in Directory.EnumerateFiles(Directory.GetCurrentDirectory(), "*.pdf"))
        {
            await using var input = new FileStream(file, FileMode.Open, FileAccess.Read);
            using var _ = Conversion.ToImage(input, page: 0, leaveOpen: false);
        }
    }
}

Environment

OS: Ubuntu 22.04
PDFtoImage: 5.2.0
.NET version: 10

Additional

On Windows, this issue does not occur.
Tried manually forcing garbage collection, but it did not help.
Tried other methods from the Conversion class, but the issue persists.

---

test_1.pdf
test_2.pdf
test_3.pdf
test_4.pdf
test_5.pdf
test_6.pdf

It seems like there might be a resource leak or an issue when multiple PDFs are processed sequentially.

[sungaila]

Hi @vsolominov,

thanks for opening this issue and for providing the code/PDF samples!

I was unable to reproduce this problem on Ubuntu 25.04 (inside WSL2) with .NET 10.

Could you please test what happens if you don't dispose the FileStream twice by setting leaveOpen: true? I suspect that calling both Dispose and DisposeAsync might cause a racing condition.

Also I'd like to know what happens if you avoid async using like this:

foreach (var file in Directory.EnumerateFiles(Directory.GetCurrentDirectory(), "*.pdf"))
{
	using var input = new FileStream(file, FileMode.Open, FileAccess.Read);
	using var _ = Conversion.ToImage(input, page: 0, leaveOpen: false);
}

Greetings
David

[vsolominov]

Hi @sungaila

I also can't reproduce the problem on Ubuntu 24.04 in Docker. However, on Ubuntu 22.04 in VBox, the issue is stable.

---

Could you please test what happens if you don't dispose the FileStream twice by setting leaveOpen: true? I suspect that calling both Dispose and DisposeAsync might cause a racing condition.

The suggested solution with synchronous resource release didn't help. Ignore double Dispose also had no effect.

---

I tried many different approaches until I decided to dive into the source code. What I managed to achieve was changing the type for FPDF_FILEACCES.m_FileLen from uint to ulong, which solved the problem - structure size increased.

I also tried using class FPDF_FILEACCESS from NuGet-package PdfiumCore - it also works correctly.

---

Therefore, my suggestion is to check int, long, uint, ulong types where necessary to ensure consistency.

Perhaps an even better option would be to use the PdfiumCore NuGet-package and interact with it and its structures.

[sungaila]

What I managed to achieve was changing the type for FPDF_FILEACCES.m_FileLen from uint to ulong, which solved the problem - structure size increased.

Thanks for checking this! I've looked into the PDFium code and you were right:

// Structure for custom file access.
typedef struct {
    // File length, in bytes.
    unsigned long   m_FileLen;

    // A function pointer for getting a block of data from specific position.
    // Position is specified by byte offset from beginning of the file.
    // The position and size will never go out range of file length.
    // It may be possible for FPDFSDK to call this function multiple times for same position.
    // Return value: should be non-zero if successful, zero for error.
    int             (*m_GetBlock)(void* param, unsigned long position, unsigned char* pBuf, unsigned long size);

    // A custom pointer for all implementation specific data.
    // This pointer will be used as the first parameter to m_GetBlock callback.
    void*           m_Param;
} FPDF_FILEACCESS;

I'll double check with the PdfiumCore project ...

[sungaila]

Well it turns out it is a lot more complicated than just changing the type from uint to ulong.

PDFium uses unsigned long for many types. The C compiler will translate unsigned long into a 32 bit integer for win-x86, win-x64 and linux-x86. However, for linux-x64 it compiles to a 64 bit long.

That's why the pdfium headers and documentation do not match, and why PDFiumCore autogenerated bindings are technically wrong. Only Linux x64 builds should use ulong.

System.Runtime.InteropServices.CULong should help for this special case (see #176) but it breaks WebAssembly for some reason. I'll need some more time to debug and test this.

[sungaila]

Hello @vsolominov,

I'm still working on fixing the WebAssembly build. In the meantime, could you please test the binaries from this pull request: NuGet packages.zip

The PDFium Interop now uses System.Runtime.InteropServices.CULong instead of uint. Therefore, linux-x64 should have been compiled correctly to ulong (while keeping the other builds untouched).

If it runs on Ubuntu 22.04, that would confirm the cause of the error and show me how to fix the issue.

Thank you very much!