Bug 269667 - Most all pages go all black once enough pdfs are open
Summary: Most all pages go all black once enough pdfs are open
Status: RESOLVED NOT A BUG
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.11.2
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-29 08:12 UTC by benson.bear
Modified: 2017-03-28 22:18 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description benson.bear 2011-03-29 08:12:58 UTC
Version:           0.11.2 (using KDE 4.5.5) 
OS:                Linux

Inevitably, once I have enough pdf files open in okular, it will start displaying the next page I go to as totally black.  Then the next and the next.  If I hit f5 I get a few good pages, then back to black.  I have to basically quite all okular instances in order for this problem to go away.  Once it starts it infects ALL open pdf files.


Reproducible: Always

Steps to Reproduce:
Open more and more pdf files in okular, and scroll around in them.  Eventually, the pages go black. 

Actual Results:  
Pages go black.

Expected Results:  
Pages do NOT go black.  There are a lot of files open, some large, so one expects some degrading of performance, like slower rendering of the next page one looks at.  But not that pages going black! I have 8G of main memory.   I never had this problem on my old machine with 1G of memory, and as many large pdfs open.

I would like to first know if anyone else has had this problem before I start specifying the particulars of my system in detail and trying to track it down.  Maybe someone already has a head start. 

But I have seen no one having this problem.

There seems to be a related problem related to X.  Discussion in some other bug threads suggest that okular allocates a lot of memory in X itself to cache page renderings, and that it shares the memory among all open instances, and that it and X do not cooperate too well on freeing this memory, with resulting performance problems.  My ears pricked up at hearing "shared memory among instances" because that might help explain how the black pages start spreading through all open instances.

See for example here: https://bugs.kde.org/show_bug.cgi?id=177213
Comment 1 benson.bear 2011-03-29 08:15:48 UTC
Should have added: I suspect perhaps a problem with the video driver (only because I never had this problem with a smaller machine and the same Fedora/Kde combo, but with different video, and because someone else mentioned this (not necessarily a good reason there)). 

I have an intel core i3 using the intel driver for the on-chip integrated graphics.
Comment 2 benson.bear 2011-03-30 09:26:11 UTC
A few more details: if I start with X at about 50M, 150M virtual, and no okular, and then open a large pdf file in okular and hit page down while under normal or aggressive performance settings, X remains at about 50M but its virtual size rises very quickly to 3G, and this is cached by the OS so cached memory rises quickly by 3G as well.  This is reasonable behavior of course since the memory is available to perform the caching.

But around this point, things go black.  In the other threads of discussion, okular developers have said that separate okular instances have no interaction, which is not what I believed at first, because if I open another okular instance at this point, everything is black whereas if I open acroread, things are renderered normally -- or so I thought.  No, some time later (although not for a while) acroread has problems as well (not quite the same -- a lot of white patches).  So I guess this means it is not really an okular bug per se. 

If I now quite the large okular instance, virtual X memory and OS cache sizes drop back to what they were before (so X has changed its behavior in this regard apparently).  Acroread works as normal, but the other okular instances have trouble and go black even though the virtual X size remains very small.  

If I quite all the okulars and start again we appear to be back to the starting point.

None of this will happen if I use okular in low performance mode.  The performance is not all that worse (it is worse though) so I guess I will resolve to keep doing this.  

I guess it is not really an okular bug, but okular pushing the system into a point where other problems become apparent, and by far most obviously so in okular itself.   I will try to try this on some other systems to see if it is repeatable with other video cards or drivers.
Comment 3 benson.bear 2011-03-30 11:40:03 UTC
Interesting observation on other machine: my little asus 1015pem with 2g ram, running same fedora 15 with its okular version, I tried the same very large pdf file, paging down in it watching memory waiting to see if I get all black.

Well, when the virtual memory size got to be around 2G for X (now well into using swap memory as well), all of sudden the virtual size of X drops way down to less than 200M. Someone decided to get rid of all the cached okular pages at that point, I guess after too much swapping was being done?  Since at that point caching has lost its point. 

So ironically I don't get the same problem on the smaller machine...
Comment 4 Anton 2011-06-22 19:22:47 UTC
I can confirm a version of this bug on:

KDE 4.6.2 (Kubuntu 11.04)
Okular 0.12.2
Machine: i7-860, 4GB Ram, NVidia GT220, Driver 270.41.19

I get random pages displayed as black in Okular, mostly when rendering DJVU files. This is most common when a blank (white) page is encountered. Normal behaviour checked in DjView 4.6. The white page displayed as black version of the problem does not usually go away when the file is reloaded or refreshed.

I do not have any particular memory use issues, as mentioned by the initial reporter.
Comment 5 benson.bear 2011-06-23 11:50:02 UTC
Anton, I don't think this is a bug.  That's just how it displays blank pages in djvu, as black pages.  Maybe white would be preferred.  I think I may have gotten it with pdfs as well, but it is no big deal.

My complaint is far far more serious: ALL (or at least VERY MANY) of the pages are black after a while, even the pages with text and other information on them.   Totally different!

I have just upgraded to Fedora 15 and the same thing happens despite having a more recent video driver.  Other folks elsewhere have said this is a problem with the intel graphics driver, so I guess I will have to upgrade to some other video card just to look at pdf files.  Bummer.
Comment 6 Anton 2011-06-23 20:53:32 UTC
Fair enough. It may be a different problem. Then, I think I have two issues:

1) The rendering of some DJVU files makes blank pages black. This does not affect all DJVU files or any PDF files. In the thumbnail viewer, the blank page will be shown as black OR sometimes as partially black with a strip copied from the next non-blank page. Occasionally it will show a complete duplicate of the next page, but still display black in the main window. I don't think this is intended behaviour.

2) I cannot reproduce it now but, occasionally, some normal text pages in DJVU files will be also displayed as black. This is usually after encountering one of the above blank pages. This doesn't seem to be as severe as what you are describing, though.

I will try to reproduce it and report back.
Comment 7 jordonwii 2012-01-05 04:48:34 UTC
benson.bear: Can you still reproduce in Okular 0.13.3? If so, can you please provide an example of a "large PDF" as well as a screenshot? Thank you for all the work you put in to monitoring and gathering information on the problem thus far.
Comment 8 benson.bear 2012-01-05 05:05:51 UTC
I can't really test it any more because I have moved to a 64 bit kernel from a 32 bit PAE kernel.  The latter, as I understand it, allows only a 3G virtual user process size out of the possible 4G address space.  It was when X reached the 3G limit that the problem arose.   So now, my X is usually about 4G virtual size and I have no problems (in one of the above messages I erroneously suggested I might have to get a new video card -- but I saw shortly afterwards that could make no difference). 

People running the PAE kernels might still be concerned with this problem.  Does the newer okular do anything about it?  It is not clear what it could do, it would be tricky, I guess.  It would have to know to what degree it was responsible for the size of the X process and then call back some of its pixmap caches when X was reaching the limit, if it was responsible.  

This is something that I guess would really have to be more global, with X calling back its pixmaps from apps when it got overextended, and that would require altering all the potentially problematic apps with code that handled such eventualities.

I guess it will remain the task of the user for quite a while to monitor this stuff...
Comment 9 Jaan Vajakas 2012-01-05 09:51:39 UTC
I switched from openSUSE 11.4 to openSUSE 12.1 and now (in Okular 13.2) I can only observe problem 1) in Comment #6 but I have not seen anymore problem 2) in Comment #6.

However, now (after upgrading to openSUSE 12.1) I have Bug 177213, which might be related to the disappearance of problem 2): if I have used Okular for some time then everything gets very slow because the computer starts to use swap memory.
Comment 10 Fabio D'Urso 2014-05-08 13:35:34 UTC
Can any of you guys that could reproduce this bug please try with Okular >= 0.19.0 ( KDE >= 4.13.0 )?
Thanks for caring about Okular :)
Comment 11 Albert Astals Cid 2017-03-28 22:18:12 UTC
No answer for years