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 <[email protected]>
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 <[email protected]> wrote:
>
>> > On 08 June 2019 at 00:23 Clemens Kolbitsch <[email protected]>
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
