白紙(読み込めない)PDFが出力されることがある

[井上翔太]

お世話になります。

C#  .NET 8.0の環境にてPDFファイルを出力した際に
相互参照テーブル(xrefテーブル)の部分が以下のようになり白紙のPDFが出力される場合があります。
Acrobat Readerなどでは該当ファイルを表示する際に読み込みエラーが発生する場合があります。
----------------------------
xref
0 2
0000000000 65535 f 
0000045557 00000 n 
3 4
0000000265 00000 n 
0000000715 00000 n 
0000000903 00000 n 
0000001091 00000 n 
8 1
0000045692 00000 n 
14 2
0000045755 00000 n 
0000045841 00000 n 
trailer
<</Size 16/Info 15 0 R/ID [<ccabd0677948675d0e2bd36b68e4a9aa><604fc03dff957f69ccdc5ea1f32981e0>]/Root 14 0 R>>
startxref
45990
%%EOF
----------------------------
同じ内容のPDFを出力した際にも発生する場合と発生しない場合があるのですが、何が原因として考えられますでしょうか？

[RapidReport]

これまで当社で把握しているケースでは、不正なPDFが出力されたという例は確認されていません。

iTextの内部仕様を把握した上で利用しているのではないため、明確な回答にはならず申し訳ありませんが、

欠番を含んだxrefテーブルが出力されているようですので、たとえば

カスタム要素レンダラなどで何らかの操作を行っている、

出力したPDFに何らかの変換を行っている、といったことはないでしょうか。

また、以下の投稿のようなことが起きているといったことはないでしょうか。

https://groups.google.com/g/rapidreport_support/c/zhEPRnRK5BM/m/V2B6lPM3AgAJ

2025年10月29日水曜日 14:56:47 UTC+9 shota...@kacoms.co.jp:

[井上翔太]

ご返信を頂戴しありがとうございます。

頂いた情報も含めてこちらで事象の詳細を調査したところ、PDFレンダラをマルチスレッドに起動したことが発生条件のようでした。
弊社要件ではマルチスレッドでの実行が必須となりますので、こちらの解消方法にご教授頂戴出来ないでしょうか？

◆再現手順
①以下のソースのMemoryStreamのサイズを測定
②まったく同じ２つのPDFの作成をマルチスレッドで起動
③結果、MemoryStreamのサイズが異なっている
→作成されるPDFファイルのサイズも異なっており、相互参照テーブル(xrefテーブル)の部分に差異がある
④仮の施行としてlockを使用してシングルスレッドで起動
⑤結果、MemoryStreamのサイズが一致する
→作成されるPDFファイルのサイズも一致する
 
--ソースを一部抜粋-------------------------------------------------------------
using (var ms = new MemoryStream())
{
    var renderer = new PdfRenderer(ms, setting);
    // PDFの画像配置
    renderer.ImageLoaderMap.Add("ActionIcon", new PdfImageLoader(getIcons()));
 
    // メタ情報
    // 作成者
    renderer.Document.AddAuthor(outputData.CreaterName);
 
    pages.Render(renderer);
 
    pdfFiles.Add((createdFileTitle, createTitle, ms.ToArray()));
}
--ソースを一部抜粋-------------------------------------------------------------
 
また、itextについて以下のような情報もあるようです。
https://kb.itextpdf.com/it5kb/release-itext-5-4-0

2025年10月30日木曜日 13:58:29 UTC+9 RapidReport:

[RapidReport]

Thread/Taskクラスなどを利用してご自身でマルチスレッド処理を実装されているということでしょうか。

すみませんが、複数のスレッドから共有して利用しているオブジェクトがないかをご確認ください。

2025年11月4日火曜日 20:20:35 UTC+9 shota...@kacoms.co.jp:

[RapidReport]

ASP.NET Coreでも問題なく利用できていたので、

オブジェクトをスレッド間で共有しなければ問題ないという認識でいたのですが、

改めて調査してみますので時間をください。

2025年11月5日水曜日 17:36:55 UTC+9 RapidReport:

[井上翔太]

お世話になります。調査のご検討を頂きましてありがとうございます。
ご指摘頂いておりましたマルチスレッドに関してはスレッドを分ける部分は弊社が実装しているという認識でお間違いありません。
また、各スレッドでインスタンスを生成しておりスレッド間におけるオブジェクトの共有については無いという認識でございます。

お手数おかけしますが、何卒ご確認よろしくお願い致します。

2025年11月6日木曜日 8:27:49 UTC+9 RapidReport:

[RapidReport]

検証したところ、ご指摘の通りの現象を確認しました。申し訳ありません。

iTextSharpの実装を含めて調査などを行っていますが、

現在のところ改善方法は見つかっておらず、

pages.renderメソッドにLockをかけて呼び出していただくという

対応しかないというのが実情です。

今後も調査は継続します。新しい情報は逐次お知らせします。

2025年11月7日金曜日 9:37:12 UTC+9 shota...@kacoms.co.jp:

[井上翔太]

ご確認頂きありがとうございます。
現象が再現できたという事で、環境特有の現象でないことに安心致しました。
ご確認を何卒よろしくお願い致します。

2025年11月12日水曜日 8:23:45 UTC+9 RapidReport:

[RapidReport]

返答までに時間がかかってしまい、申し訳ありません。

調査したところ、壊れたPDFファイルが生成される現象は、

プロセス内で最初のPDF出力を並列実行している場合に発生していました。

そこで、プロセスの起動直後にダミーの帳票出力処理を実行するということを

試していただけますでしょうか。

添付したdummy.rrptを用いて以下のコードをメインスレッドで同期的に実行してみてください。

            Report report = new(Json.Read("dummy.rrpt"));
            report.Fill(DummyDataSource.GetInstance());    
            ReportPages pages = report.GetPages();
            using(MemoryStream ms = new())
            {
                PdfRenderer renderer = new(ms);
                pages.Render(renderer);                
            }

2025年11月13日木曜日 22:23:32 UTC+9 shota...@kacoms.co.jp:

[井上翔太]

ご確認頂きありがとうございます。
「プロセス内で"最初"のPDF出力を並列実行している場合」に発生するため、事前にダミーの帳票出力を行い"最初の実行では無くす"という認識であっていますでしょうか？

 ・現行(3スレッドの場合)→最初のPDF出力のため発生
───────┬(PDF出力)─
　　　　　├(PDF出力)─
　　　　　└(PDF出力)─

 

・試行(3スレッドの場合)→事前にダミーを実行し問題が発生しない想定
─(dummy)──┬(PDF出力)─
　　　　　　├(PDF出力)─
　　　　　　└(PDF出力)─

2025年11月18日火曜日 9:52:38 UTC+9 RapidReport:

[RapidReport]

その通りです。

目的の通常のPDF出力を行うよりも前にダミー出力を行ってみていただくようお願いします。

2025年11月19日水曜日 9:46:40 UTC+9 shota...@kacoms.co.jp:

[井上翔太]

お世話になります。

ご提案いただいた回避策（プロセスの起動直後にダミーの帳票出力処理を実行）について、こちらで検証を実施いたしました。
結果としましては、何度かプロセス実行したところ（7回目）、同様の事象が再現いたしました。
そのため、「プロセス内で最初のPDF出力時にのみ発生する」という状況ではない可能性が高いと考えられます。

 

つきましては、以下の2点について、お手数ですがご確認・ご検討をお願いできますでしょうか。
・可能であれば、どのような経緯や条件で「初回のみ」という結論に至ったのか、参考に教えていただけますでしょうか。
・ダミー出力による回避が難しいため、恐縮ながら、根本原因の調査を改めてお願いできますでしょうか。

2025年11月19日水曜日 12:22:59 UTC+9 RapidReport:

[RapidReport]

添付したコードで検証を行いました。

10件の帳票を並列で出力する処理を3回行うプログラムを実行したところ、

必ず1回目に出力した10件のうち1件だけが壊れたPDFとなり、

2-3回目に出力された帳票は壊れていない、という結果となりました。

そこで、先に投稿したように「プロセスの最初の並列実行で壊れたPDFができてしまう」

と考え、最初にダミー帳票出力を同期的に行ったところ、

3x10件の帳票が壊れずに出力された、という経緯になります。

10回程度は試行してみて、その際は現象が発生しなかったのですが、再び調査してみます。

根本原因についてはiTextSharp内部を含めていま一度調査を行ってみますが、

すみませんが出力処理の排他実行を行って頂くしかないかもしれません。

pages.Render()関数の呼び出しにのみlockをかけた場合でも、

パフォーマンス要件を満たせなくなってしまうでしょうか？

2025年11月26日水曜日 9:55:42 UTC+9 shota...@kacoms.co.jp:

[RapidReport]

回答に時間がかかりすみません。

ご指摘の通り、ダミー帳票を出力する方法では解決になっていないことを確認しました。申し訳ありません。

改めてiTextSharpの内容を調査し、並列処理の場合にxrefテーブルに欠番が生じる原因になっていると考えられる箇所に修正を加え、

複数の条件でPDF出力を行い、不正なファイルが出力されなくなることを確認しました。

以下のリンクからダウンロードできますので、含まれている systembase.iTextSharp.dll を使用していただくようお願いします。

https://rapidreport.systembase.co.jp/support/support202512051.zip

ダウンロードしたら右クリックして「プロパティ」「全般」の

「セキュリティ：このファイルは他のコンピュータから取得したものです・・・」に「許可する」チェックを入れてから解凍してください。

2025年11月26日水曜日 12:27:49 UTC+9 RapidReport:

[井上翔太]

お忙しい中、ご対応を賜りまして誠にありがとうございます。

頂きましたファイルで再現していた現象が起きなくなるかを検証いたします。

引き続きよろしくお願い致します。

2025年12月5日金曜日 9:36:35 UTC+9 RapidReport:

[井上翔太]

お世話になります。

ご提案いただいた回避策（添付いただいた systembase.iTextSharp.dll を使用した実行）について、以下の通り検証を行いました。

・反映手順
ダウンロード後、右クリック → 「プロパティ」 → 「全般」 → セキュリティ項目で「許可する」にチェック
解凍後、で dotnetcore_pdf 内の systembase.iTextSharp.dll を弊社環境（C# / .NET 8.0）のプロジェクトフォルダ/libの同名ファイルに上書きし実行
・ 検証内容
3件同時PDF出力を並列処理 × 10回検証
・ 結果
10回中、5回xrefが破損しており、そのうち3回はPDFを開いたときに白紙となっていました
白紙となったPDFのxrefの例
----------------------------
xref
1 1
0000042185 00000 n
3 3

0000000265 00000 n
0000000715 00000 n

0000042319 00000 n
11 2
0000042382 00000 n
0000042468 00000 n
trailer
<</Size 13/Info 12 0 R/ID [<5ac70a0d7a4f16d14d1ee0322705a5e8><dd15f8ab47f0db141fdd3128cbf33911>]/Root 11 0 R>>
startxref
42618
%%EOF
----------------------------

・ ご確認事項
systembase.iTextSharp.dll を使用した実行は上記手順で問題ありませんでしょうか？
手順に間違いなければ、お手数ですがご確認をお願いしたいと思っております。

何卒よろしくお願い致します。

2025年12月8日月曜日 15:37:50 UTC+9 井上翔太:

[RapidReport]

dllファイルはビルド時に更新されているかを確認お願いいたします。

ビルド結果の出力フォルダにあるsystembase.iTextSharp.dllのプロパティ>詳細のファイルバージョンは4.1.6.3になっているでしょうか。

※ 4.1.6.2の場合は古いファイルのままです。

2025年12月10日水曜日 16:24:54 UTC+9 shota...@kacoms.co.jp:

[井上翔太]

ご連絡が遅くなり申し訳ありません。
確認したところ仰るようにdllが更新されていなかったようです。
ご対応内容で今まで通りの手順で再現しないことを確認しております。
ご対応頂きましてありがとうございます。

2025年12月11日木曜日 9:33:29 UTC+9 RapidReport: