Highlighting 5-10 textpositions in a pdf leads to crash every time. Unfortunately, drkonqi is not triggered here, thus I do not have a backtrace. It is not limited to long pdfs as first thought (https://bugs.kde.org/show_bug.cgi?id=375506)
Thanks for reporting, but I cannot reproduce with a self-compiled Okular 17.12 Beta on Tumbleweed (you mentioned in the other bug that you were using Tumbleweed, too) as well as the Beta one from KDE:/Applications/KDE_Frameworks5_openSUSE_Tumbleweed. Please attach a PDF which is crashing for you and a provide a screenshot (or screen recording) of the highlights right before the crash. Do you get any additional output when starting Okular from a console? To manually create a backtrace, refer to https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB
console output: okular Flow_Guideline.pdf QFSFileEngine::open: No file name specified Illegal icon group: 7 kf5.kio.core: Invalid URL: QUrl("Flow_Guideline.pdf") kf5.kio.core: Invalid URL: QUrl("Flow_Guideline.pdf") Segmentation fault (core dumped)
The pdf I currently use is found here (too large to upload as attachment): http://onlinelibrary.wiley.com/doi/10.1002/eji.201646632/pdf
Thanks for the additional info. Console output looks normal, except for the last line ;) However, I still could not reproduce the crash. More ideas to try: - What does "Highlighting 5-10 textpositions" mean exactly? Try uploading a screenshot right before the crash. - Provide a backtrace, so we can see in which direction to investigate further. - Do you have any additional repositories enabled? This sometimes leads to weird side effects for libraries like Poppler (Okular's PDF rendering backend). - Is you system fully up-to-date with "zypper dup"? - Perhaps this is a graphics driver issue? Which driver do you use? Do you have another system with different hardware to test on? - Try "repairing" the PDF with "qpdf in.pdf out.pdf" and see if it still crashes.
Created attachment 109111 [details] okular backtrace 1
-bt and screenshot attached -system is fully upgraded -modesetting with an intel skylake is in use I hope that helps
Created attachment 109112 [details] screenshot
Sorry to say, still cannot reproduce the crash (and I tried _very_ hard). Looking at the backtrace and your hardware, I got another idea. Please run the following two commands and provide the output (the second one might need "zypper in xdpyinfo"): - grep DPI /var/log/Xorg.0.log - xdpyinfo | grep -B2 resolution Also: Can you confirm highlighting the same way in another PDF does not lead to a crash? And just to be sure: You do not have a touchscreen by any chance, do you? (BTW, seeing you removed the menubar: To get even more vertical space, Okular allows to remove the bottom bar too and add it back again as a "button" in the toolbar.)
Here the outputs: - grep DPI /var/log/Xorg.0.log: [ 188.617] (==) modeset(0): DPI set to (96, 96) [ 188.965] (II) event7 - (II) Logitech MX Master: (II) device set to 1000 DPI [ 188.980] (II) event7 - (II) Logitech MX Master: (II) device set to 1000 DPI [ 2212.944] (II) event7 - (II) Logitech MX Master: (II) device set to 1000 DPI [ 2212.984] (II) event7 - (II) Logitech MX Master: (II) device set to 1000 DPI - xdpyinfo | grep -B2 resolution screen #0: dimensions: 1920x1080 pixels (508x285 millimeters) resolution: 96x96 dots per inch Highlighting the same way lead to a crash in at least one other pdf too. I do not have a touchscreen (using a tuxedo infinity book 13 v2).
Hmm, looks normal, too. Not sure what to do now. After playing around some more, I could finally observe a crash. Unfortunately, I'm not able to crash Okular a second time to capture anything… Albert: Do you see any hints in the backtrace? When setting a breakpoint on Page::width, pressing the mouse button and moving a single pixel to select (no matter whether annotation or regular text selection), I get the same backtrace, without the crash of course. I looks quite normal, but why would it crash afterwards?
(In reply to Robby Engelmann from comment #3) > The pdf I currently use is found here (too large to upload as attachment): > http://onlinelibrary.wiley.com/doi/10.1002/eji.201646632/pdf Please send us one with all your existing annotations and also describe clearly which annotation you add and in which page.
Created attachment 109208 [details] other example
I attached a pdf as an example. However, it does not matter which pdf is used. If I use the text highlighting annotation, okular will crash after adding 3-8 further highlights to a previously saved pdf containing text highlighting annotations.
Not to forget: It is also the same for the 1.2.90 version of okular (RC of KDE apps 17.12).
(In reply to Robby Engelmann from comment #14) > Not to forget: It is also the same for the 1.2.90 version of okular (RC of > KDE apps 17.12). So you get the crash both on 1.2.90 and say 1.2.3?
(In reply to Robby Engelmann from comment #13) > I attached a pdf as an example. However, it does not matter which pdf is > used. If I use the text highlighting annotation, okular will crash after > adding 3-8 further highlights to a previously saved pdf containing text > highlighting annotations. Still can't reproduce, could you run valgrind okular myfile.pdf on a terminal (it will be slower) and do what you usually do to make it crash and then paste here the output of the valgrind command on the command line?
For both documents, I can now reproduce the crash pretty reliably: - Add highlighting annotation. - Save document. (← This is an essential prerequisite.) - Scroll to a new page to trigger rendering (← Somehow this is needed to get in a bad state, but only for the first document.) - Keep adding more highlighting annotations and scrolling further until the crash triggers (it won't always crash for the first one). (IOW, it's important to be as detailed as possible when reporting a bug and when requesting information from a bug reporter, otherwise it's just plain guessing…) In fact, even with autotests/data/file1.pdf a crash is now trivial to trigger (highlight → save → highlight). I bisected back and forth in both Okular and Poppler, and ultimately Okular's ca5422d0e9ad ("Implement swapBackingFile for the PDF backend") is the culprit (tested with Poppler master). The only explanation I have is that the new annotation saving feature was mainly tested with the pen tool, but less so with the highlighter, which was not wise reading that commit message now. Albert: Backtrace is the same as above, let me know if you still cannot reproduce and need the Valgrind log. Removing "qDeleteAll( pagePrivatesToDelete )" fixes the crash for me, because then accessing "d" in "Page::width" won't segfault anymore. However, now "d" leaks obviously. Any tips on how the oldPage/newPage pointer swapping is supposed to work and the leak could be prevented? Otherwise, I'd say leaking a little bit is better than crashing, given that the final release is tomorrow…
Oki, I learn to be as precise as possible the next time. I did not expect, that saving is the important point here, although I am well aware that I saved always before the bug got triggered.
Git commit 4e6c9f8f7ab5369528802a5012865523afb4747b by Albert Astals Cid. Committed on 05/12/2017 at 22:07. Pushed by aacid into branch 'Applications/17.12'. Fix crash when accessing text page after save text page was storing a pointer to a PagePrivate pointer but those die after saving so we need to store a Page pointer since those are stable. M +2 -2 core/page.cpp M +12 -10 core/textpage.cpp M +1 -1 core/textpage_p.h https://commits.kde.org/okular/4e6c9f8f7ab5369528802a5012865523afb4747b
Robby: Thanks again for testing the Beta and RC releases. You were the only one reporting this serious bug with the new annotation saving feature, even though it will affect almost everybody using highlighting. Keep beta testing, so we have a chance to fix mistakes in time ;) Albert: Thanks for the fix.