Tried the patch, but didn't really help. BUT: I'm actually a bit surprised by the patch itself:
+ if ( NULL != m_pOutputStream ) + m_pOutputStream->Close(); + delete m_pOutputStream; Isn't the "if" essentially a NOP? If m_pOutputStream were NULL, the delete would segfault in every case (as you're deleting NULL) -Clemens On Tue, Jun 11, 2019 at 9:55 PM Clemens Kolbitsch <kolbit...@lastline.com> wrote: > Thanks for the super fast response, and yes, I'm on the list :-) Will test > the patch shortly and post results > > On Tue, Jun 11, 2019, 17:32 Matthias Brinke <ma...@mailbox.org> wrote: > >> > On 08 June 2019 at 00:23 Clemens Kolbitsch <kolbit...@lastline.com> >> wrote: >> > >> > Hi list! >> > ...snip... >> > As before, I unfortunately cannot share the file, but after some >> > tracing, I believe the problem is that PdfStream::GetFilteredCopy >> > is creating "nested" output stream via >> > PdfFilterFactory::CreateDecodeStream. With "nested" I mean that the >> > stream contains "owned" output streams generated in this loop: >> > PdfFilteredDecodeStream* pFilter = new PdfFilteredDecodeStream( >> > pStream, *it, false, pDictionary ); >> > ++it; >> > >> > while( it != filters.rend() ) >> > { >> > pFilter = new PdfFilteredDecodeStream( pFilter, *it, true, >> pDictionary ); >> > ++it; >> > } >> > >> > return pFilter; >> > That is, we enter the loop and create the nested pFilter. This object, >> > from what I can see, is never being closed, meaning that when the >> > auto_ptr calls the destructor, we hit this >> assert:PdfFilter::~PdfFilter() >> > { >> > // Whoops! Didn't call EndEncode() before destroying the filter! >> > // Note that we can't do this for the user, since EndEncode() might >> > // throw and we can't safely have that in a dtor. That also means >> > // we can't throw here, but must abort. >> > assert( !m_pOutputStream ); >> >> thanks for your analysis, this seems to be correct (IMHO, I've also >> looked at >> this code only recently, at since some years). I've attached a proposed >> patch, >> please test. >> >> > Without a full understanding of the code, this may be more guessing >> than a >> > good pointer, but it seems we may not be calling EndDecode when writing >> > fails (of if it is never triggered on the nested output stream). >> >> When writing fails, PdfFilter::FailEncodeDecode() is called, which does >> close >> and NULL it. When it hasn't, the destructor of PdfFilteredDecodeStream >> doesn't >> close the underlying stream before deleting it, thereby causing the >> assertion >> failure AFAICS w/o test file. >> >> > I'm happy to do any debugging you need, but hopefully the stack-trace >> above >> > helps identify the issue. >> > ...snip... >> >> Please test with the attached patch, I hope it fixes the issue (for >> decoding, >> on the encoding side it'd be a different issue, right?). >> >> > Thanks! >> > -Clemens >> >> P.S. @Clemens: I don't know if you're subscribed to the list, so I've >> sent this >> e-mail to you also directly. > > -- *Clemens Kolbitsch* Director of Engineering, Lastline Cloud and Infrastructure www.lastline.com Lastline Advanced Network Security | AI Done Right
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users