evince crash when read pdf file

[tri m s]

Binary package hint: evince

Ubuntu 9.04
evince 2.26.1-0ubuntu1

when i tried to open a pdf, in just 2 second evince will crash.

here is the error message that i got when run evince from terminal:

Error (0): Call to Object where the object was type 5, not the expected type 8
Aborted

seems it same like report at https://bugzilla.redhat.com/show_bug.cgi?id=512701

[tri m s (trims)]

Binary package hint: evince

Ubuntu 9.04
evince 2.26.1-0ubuntu1

when i tried to open a pdf, in just 2 second evince will crash.

here is the error message that i got when run evince from terminal:

Error (0): Call to Object where the object was type 5, not the expected type 8
Aborted

seems it same like report at https://bugzilla.redhat.com/show_bug.cgi?id=512701

[Dimitrios Symeonidis (azimout)]

This happens with all files, or only a specific one?

[tri m s (trims)]

no, it only happen with pdf file that contain image as page background.
sample file: http://is.gd/2CVZK

[Dimitrios Symeonidis (azimout)]

confirming the crash on latest Karmic, the error message is the same

[Dimitrios Symeonidis (azimout)]

extracting the pdf from the archive was a pain (rapidshare, multiple archives in .zip, broken into multiple rar archives), attaching the actual pdf file

[Dimitrios Symeonidis (azimout)]

added the fedora bug watch

[Dimitrios Symeonidis (azimout)]

note: the file opens without a problem on xpdf, acroread and okular

[Sebastien Bacher (seb128)]

There is a similar crash on https://bugs.launchpad.net/bugs/419777

example: http://launchpadlibrarian.net/31038402/Wiley.OpenSolaris.Bible.Feb.2009.pdf

the issue is there using 0.11.3 too

[Carlos Garcia Campos (carlosgc)]

I think they are different issues. The first one was a bug in evince that we already fixed some time ago. The second looks like a broken pdf file, it contains a FileSpec object with an empty EF dictionary:

4205 0 obj <</UF(C1.jpg)/F(C1.jpg)/EF<<>>/Desc()/Type/Filespec>> endobj

I'd say this is wrong . . .

In any case we shouldn't crash when EmbFile contains a null stream. Albert, does this make qt frontend crash too? or do I mark this bug as glib only?

[Sebastien Bacher (seb128)]

should this bug be closed if the issue was a fixed evince one and a new one opened about the new crash?

[Sebastien Bacher (seb128)]

The crash is similar to bug #94903

[Albert Astals Cid (aacid)]

Crashes too on the Qt frontend, the question is, should we "stop" reporting the Embedded file from the core when we realize it's not a valid one or still report it and fail when trying to save it.

Adobe does the later, but for us would be easier the first and for the user the result is the same as he can't extract the file.

But still i think we should go fixing the frontends, what do you say?

[Carlos Garcia Campos (carlosgc)]

An attachment that can't be opened/saved/... is useless, so I think we might just show an error message saying that an invalid embedded file has been found and ignore such attachment.

[Albert Astals Cid (aacid)]

Carlos: At the end Pino and me think that mimicking Adobe's behaviour is the best so i've added a isOk() method to EmbFile in poppler core you should use in the glib frontend to avoid the crash.

[Carlos Garcia Campos (carlosgc)]

Ok, fixed in glib too. Thanks!

[Sebastien Bacher (seb128)]

the bug has been fixed upstream now

[Sebastien Bacher (seb128)]

The bug is fixed in the karmic and lucid versions