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.
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
