Bug 341118

Summary:	Okular blocks (no display, no menu), when scrolling down or opening pdf document.
Product:	[Applications] okular	Reporter:	NuageBleu
Component:	PDF backend	Assignee:	Okular developers <okular-devel>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	aacid, jonathan.verner
Priority:	NOR
Version:	0.20.2
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
URL:	http://www.fairphone.com/wp-content/uploads/2013/09/Fairphone_Cost_Breakdown_and_Key_Sept2013.pdf
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	sample PDF which makes Okular to crash

Description NuageBleu 2014-11-20 10:20:34 UTC

For a few months Okular stops working (no display, no menu) with some pdf that I read over internet.
All the pdf that I can generate with LibreOffice are working fine fine.
I finally found a public pdf file that allows systematic crash:
- sometimes when opening the pdf document
- otherwise simply scrolling down


Reproducible: Always

Steps to Reproduce:
1. Open the Fairphone_Cost_Breakdown_and_Key_Sept2013.pdf
2. If it didn't crash yet, scroll down


Actual Results:  
It hang (looks like an infinite loop or something) with no move possible.

Comment 1 NuageBleu 2014-11-20 10:21:53 UTC

Created attachment 89644 [details]
sample PDF which makes Okular to crash

Comment 2 Albert Astals Cid 2014-11-20 21:50:46 UTC

Works fine here, does it crash or not? Because reading your text is not clear to me.

Comment 3 NuageBleu 2014-11-21 10:20:29 UTC

Sorry for being unclear. Here it is, when the problem occurs:
- Okular doesn't exits (the windows is still open).
- Okular stops working (can't scroll or access any menu).

(I can also add that on an other computer with Debian Wheezy (soon the old stable) the issue is not present, Okular Version 0.14.3)

Comment 4 Jonathan Verner 2014-11-22 12:10:31 UTC

Hmm, this sounds vaguely like Bug 329740... Is it possible, that you have a default printer in CUPS which is unreachable (e.g. because you are on a different network)?

Comment 5 Albert Astals Cid 2014-11-22 15:22:46 UTC

Might be, does it fix itself after 30 seconds?

Comment 6 NuageBleu 2014-11-24 08:17:35 UTC

Yes, it does recover after 30[s].
The problem is that scrolling back or further will hang it again for 30[s].

More precisely it is apparently trying to solve some 'flash-Virt' host name.
It blocks on it 6 times for 5[s] each.
I could find it using strace, here is where it's blocking, while waiting for the read() to return data:

$ strace okular
[...]
write(21, "RESOLVE-HOSTNAME-IPV4 flash-Virt"..., 45) = 45
read(21,

Comment 7 Albert Astals Cid 2014-11-24 18:22:12 UTC


*** This bug has been marked as a duplicate of bug 329740 ***