Bug 329600 - PDF's are rendered as blank pages.
Summary: PDF's are rendered as blank pages.
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 0.17.4
Platform: Fedora RPMs Linux
: NOR grave
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-04 15:59 UTC by Larry
Modified: 2014-02-17 22:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Sample document (293.61 KB, application/pdf)
2014-01-04 16:02 UTC, Larry
Details
strace from failing machine (81.14 KB, application/gzip)
2014-01-05 16:16 UTC, Larry
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Larry 2014-01-04 15:59:46 UTC
I have used Okular to review scanned documents for several years.  Starting yesterday afternoon, most of the scanned documents are rendered with the last page being blank.  Single-page documents are entirely blank.  The only changes made between working and not are that I installed and removed DIGIKAM:
Jan 03 10:29:24 Installed: libkface-3.5.0-2.fc20.x86_64
Jan 03 10:29:24 Installed: libpgf-6.13.45-0.1.svn123.fc20.x86_64
Jan 03 10:29:25 Installed: liblqr-1-0.4.1-5.fc19.x86_64
Jan 03 10:29:30 Installed: digikam-3.5.0-2.fc20.x86_64
Jan 03 10:29:30 Installed: digikam-libs-3.5.0-2.fc20.x86_64
Jan 03 10:43:20 Erased: digikam-3.5.0-2.fc20.x86_64
Jan 03 10:43:21 Erased: digikam-libs-3.5.0-2.fc20.x86_64
Jan 03 10:43:22 Erased: libkface-3.5.0-2.fc20.x86_64
Jan 03 10:43:23 Erased: liblqr-1-0.4.1-5.fc19.x86_64
Jan 03 10:43:23 Erased: libpgf-6.13.45-0.1.svn123.fc20.x86_64

The workstation is updated regularly.  The same PDF's are properly rendered with Adobe PDF Reader and Okular on a different workstation.  No obvious errors are visible under /var/log or in .xsession-errors, even if I load Okular from a shell prompt.

There are no crashes.

Reproducible: Always

Steps to Reproduce:
1.  Open PDF from Dolphin or execute "okular DOCUMENT-NAME" at shell.
2.
3.
Actual Results:  
Blank page is displayed for single-page documents and documents with blank last page for multi-page documents.

Expected Results:  
reasonable display of all pages.
Comment 1 Larry 2014-01-04 16:02:04 UTC
Created attachment 84449 [details]
Sample document

This scanned document displays properly on other workstations but displays as a single blank page on this one.
Comment 2 Albert Astals Cid 2014-01-04 16:35:19 UTC
Well if the document is displayed on other workstations and not in this one, maybe you can check what's the differences between the workstations?
Comment 3 Larry 2014-01-05 16:15:49 UTC
I found no relevant differences between 2 Fedora 20 workstations, one exhibiting the problem and the other not, both with  the same package versions.  I executed Okular on both with strace output to files and compared them.  The only significant differences begin at line 16219 in the attached strace log (uploaded) where there is a nearly constant stream of "recvfrom" errors, probably in a message loop but you would know better.

I'm not sure if it's relevant but I did notice  many occurrences of blocks of code "swapped" between what should have been similar(different only by memory addresses or file descriptors) log files.  Especially when the blocks of code were reading libraries or configuration files.  The return values of the various file-existence checks were consistent but the 2 traces would then read or check blocks of files in different order.  For example, the block of code in lines 546 through 553 occurs on the failing machine prior to the block of code in lines 554 throu 568 whereas it occurs on the working machine prior the second block.

Perhaps you can see an obvious cause for the problem that I don't.

Thanks for your time and attention.
Comment 4 Larry 2014-01-05 16:16:59 UTC
Created attachment 84464 [details]
strace from failing machine
Comment 5 Albert Astals Cid 2014-01-06 20:56:06 UTC
I can reproduce the error and the only reason I can find for the other machine to work is that you are "lying" and it is not running the same poppler version since an older poppler version used to work. Anyway I've now fixed it and poppler 0.26.0 will work again.
Comment 6 Larry 2014-02-17 22:08:23 UTC
(In reply to comment #5)
> I can reproduce the error and the only reason I can find for the other
> machine to work is that you are "lying" and it is not running the same
> poppler version since an older poppler version used to work. Anyway I've now
> fixed it and poppler 0.26.0 will work again.

I'm confused by this response.  Poppler versions are in the 0.24, not close to 0.26.  Also, you mark this as resolved and say you fixed it but what was fixed (project, file and version, please?)  What was the bug in Poppler (so I can track it) and did you forward the issue to them (what BZ #)?
Comment 7 Albert Astals Cid 2014-02-17 22:20:11 UTC
Next poppler version is 0.26, obviously i can't have fixed it in an already released version, no?

What was fixed? The bug in poppler that caused this.

Did i forward anything? No, since i'm the maintainer of poppler i don't need to forward myself stuff

If you want to find out where the bug is i recommend you to do search for "poppler kde bug 329600" in google or any other good enough browser and find what you want.