You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Andreas Lehmkühler (Jira)" <ji...@apache.org> on 2022/01/27 07:28:00 UTC

[jira] [Commented] (PDFBOX-5369) PDDocument.saveIncremental () and stack exhaustion

    [ https://issues.apache.org/jira/browse/PDFBOX-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482926#comment-17482926 ] 

Andreas Lehmkühler commented on PDFBOX-5369:
--------------------------------------------

The root cause is your own code. You are simply reusing COS-objects imported as fdf when adding them to the pdf:
{code}
...
PDAnnotation pa = PDAnnotation.createAnnotation (a.getCOSObject ());
...
{code}
Those objects include indirect object references which may be mixed up with already existing objects in the pdf. In your case object 2 0 in the fdf file contains a reference to the object 3 0
{code}
2 0 obj
<</C[ 1 1 0]/T(Foxit Web)/Rect[ 46.072 789.125 66.072 809.125]/F 28/Contents(alo)/Subtype/Text/Type/Annot/Subj(Note)/Name/Comment/Popup 3 0 R /CreationDate(D:20220120215651+01'00')/M(D:20220120215700+01'00')/CA 1/NM(5ef4c1db-28a4-4ac7-999b-de6e2508d84b)/Page 0>>
endobj
{code}
The pdf contains object 3 0 as well (it contains the length of a stream)
{code}
3 0 obj
125
endobj
{code}
Either you have to ensure that such references are dereferenced or removed before using those objects or you simply copy the needed values from the imported object to a new created one. The latter is done in {{org.apache.pdfbox.tools.ImportFDF}}


> PDDocument.saveIncremental () and stack exhaustion
> --------------------------------------------------
>
>                 Key: PDFBOX-5369
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-5369
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Writing
>    Affects Versions: 3.0.0 PDFBox
>            Reporter: the blue mountain
>            Priority: Major
>         Attachments: PDFBOX-20220126.zip
>
>
> Merge of fdf annotations into pdf file exhausts stack
> attempting to merge an fdf file in a pdf file, using the PDDocument.saveIncremental () method, program stack is exhausted because of infinite recursion.
> looking further in the code, it seems the infinite recursion is being started from the private boolean COSIncremental.collect(COSBase base) method.
> i have attached a zip file carrying:
> - mini.pdf: a minimal pdf file to reproduce the issue
> - mini.fdf: an fdf annotation file carrying a /Text annotation and related /Popup to reproduce the issue
> - COSIncrement.java: a modified source that generate extra traces (+ possible work-around)
> - COSIncrement-fix.java: a modified source to avoid the problem
> - Sample.java: a sample program that loads pdf, copies annotations and saves incrementally.
> - sample_run.xlsx: an extract of the Sample output to compare a working vs non-working
>  
> notes:
> 1- I was not able to reproduce the problem using annotations created dynamically in the code.
>  
> 2- It is possible to avoid this issue by altering the COSIncrement.java class (COSIncrement-fix.java):
> it records objects beING collected through enter () method ensuring object is not being collected multiple times
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org