@zyx <z...@gmx.us> Increasing the s_maxRecursionDepth would defeat the purpose of the RecursionGuard. The guard is already aligned to the typcial stack size of 256, so increasing the max would just open door to stack overflows the guard is meant to prevent. If anything, the guards max value may actually be to big, since it does not leave "wiggle room" for client code using podofo. You can increase the stack, thats true, but that would just be a bandaid fix. As soon as an even bigger pdf file comes alone, it might crash again. The parsing code should not use an recursive approach, thats the design flaw, imo. The recursion guard is meant to mitigate that, but the whole process seems to have its own flaw somewhere.
@Christopher At least in this place, the caught exceptions do get rethrown, so there is no new exception with every catch: try { ReadNextTrailer(); } catch( PdfError & e ) { if( e != ePdfError_NoTrailer ) { e.AddToCallstack( __FILE__, __LINE__ ); throw e; } } But with every catch, an additional line is added to the internal call stack (a string collection) of the error object. Maybe thats the issue here, the error object getting larger with every catch, and eventually busting the stack frame? I don't know, but thats the first thing I'm going to try out, commenting out this AddToCallstack cakks and check if it still crashes. If it does, removing the try catch-clauses altogether (in the recursively called functions), and let the try-catch clasues in ReadDocumentStructure handle it. If that STILL causes stack overflow during excpetion unwinding for my file, I'm dead lost. @Michal Yes, I saw that XRefStm takes part in the recursion as well, but I left it out for simplicity. Its also not relevant in my use case, the pdf I'm testing with does not have xref tables as streams. But for a proper rework of the parsing, that streams need to be handled as well, sure. I also thought about using a stack / queue for xref offsets to check, but I'm just not familiar enough with the whole parsing process to hack something like that myself ^^ Greetings, F.E. Am Di., 30. Jan. 2024 um 23:00 Uhr schrieb Michal Sudolsky < sudols...@gmail.com>: > >> right? When you set the s_maxRecursionDepth to large-enough value, will >> PoDoFo be able to open the file? Possibly also making the stack larger, >> to accommodate the recursion. >> >> > I suppose it will work fine. Using recursion there is not a very good > idea. Also there are two keys that need to be followed: "XRefStm" and > "Prev". @Francesco Pretto <cez...@gmail.com> maybe you could fix that in > the new podofo? Something like this could work for example (pseudocode): > > xrefs - vector of xrefs (or stack); > checked - set of already checked xrefs; > xrefs.push_back(first xref - startxref); > while(!xrefs.empty()) > { > XRefType xref = xrefs.back(); > xrefs.pop_back(); > if(checked.contains(xref))continue; // to avoid cycles > checked.insert(xref); > ... > just check whether this is non-stream xref with trailer - > xrefstream contains just single "previous xref" > xrefs.push_back(next "XRefStm" key from trailer); > xrefs.push_back(next "Prev" key from trailer); > } > > > >> _______________________________________________ >> Podofo-users mailing list >> Podofo-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/podofo-users >> > _______________________________________________ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users >
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users