Bugs item #2487687, was opened at 2009-01-05 13:34
Message generated for change (Comment added) made by pierre_marchand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=790130&aid=2487687&group_id=154028

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: podofoimpose segfault ibn scribus's PDFs

Initial Comment:
podofoimpose (0.7.0) segfaults on Scribus  1.3.5 PDF files with embedded fonts 
(e.g. DejaVu Serif). GDB backtrace is attached.

Any test file from  1.3.5 (didn't try stable) will work. Confirmed by another 
user.

----------------------------------------------------------------------

Comment By: Pierre (pierre_marchand)
Date: 2009-01-09 13:22

Message:
I was willing to fix what seems to be plain bug but I found that the
control code in migrateresource should prevent such an infinite recursion,
look:
"[…]
else if ( obj->IsReference() )
                        {
*** Here we check this reference has not been copied already.
*** I think it’s enough to prevent recursion, may I be wrong.
                                if ( migrateMap.find ( 
obj->GetReference().ToString() ) !=
migrateMap.end() )
                                {
                                        return 
migrateMap[obj->GetReference().ToString() ];
                                }

                                PdfObject * o ( migrateResource ( 
sourceDoc->GetObjects().GetObject (
obj->GetReference() ) ) );

                                ret  = new PdfObject ( o->Reference() ) ;

                        }
*** Here it’s expected to perform the copy of "leaves" of objects
*** which are not indirect references. Those can’t reference themselves,
at least i believe.
                        else
                        {
                                ret = new PdfObject ( *obj
);//targetDoc->GetObjects().CreateObject(*obj);
                        }


                        migrateMap.insert ( std::pair<std::string, PdfObject*> (
obj->Reference().ToString(), ret ) );
[…]"

So, I can add a static deepness counter and a compile time MAXDEEPRESOURCE
constant, but I would be relieved if someone could say what’s wrong here.
Thus I could rewrite it without any hack.




----------------------------------------------------------------------

Comment By: Pierre (pierre_marchand)
Date: 2009-01-07 01:44

Message:
Good catch, there ’s no check about how deep migrateResource goes, which
is bad obviously. Now, the PDF would be interesting to see if we are in an
infinite loop, for which we check, but the checking method could fail.

----------------------------------------------------------------------

Comment By: Alexandre Prokoudine (prokoudine)
Date: 2009-01-06 20:09

Message:
Craig, it's tens of thousands of migrateResource() fails, not hundreds. In
fact I had to power off my laptop because gdb just froze X session. I will
attach PDF file asap.

----------------------------------------------------------------------

Comment By: Craig Ringer (ringerc)
Date: 2009-01-05 15:53

Message:
That's odd. It looks almost like it could be an out-of-memory condition,
but usually that'd result in a SIGABRT (signal 6) not a SIGSEGV.

Your libc isn't debug enabled, nor is your build of PoDoFo or libstdc++,
so it's a bit hard to tell exactly what's going on; I can really only see
that it's crashing while converting a PDFReference to its string
representation, in the process of which it's having to expand a
std::string, trying, and failing during memory allocation. This could be
due to memory exhaustion, a stack overflow, or of course something else
entirely.

Since a PDFReference is of the fixed form "[integer] [integer] R", memory
exhaustion is presumably not the immediate problem. We won't be allocating
vast amounts of memory for that. So it must be in some kind of infinite or
at least very deep loop where it's creating lots of objects and not
releasing them - or where the depth of the call stack is its self the
problem. That's presumably an issue in migrateResource().

Your backtrace is incomplete - are there LOTS of calls (hundreds?) to
migrateResource() by any chance?

It'd be helpful if you could attach a PDF just so we're all talking about
the same file when looking at this. I don't have Scribus 1.3.5 at present
and would rather have something I know crashes for you anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=790130&aid=2487687&group_id=154028

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to