[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #19 from Tobias Deiminger --- (In reply to Albert Astals Cid from comment #18) > The timer is not the problem, that timer gets triggered quite easily and > doesn't infinite loop. > > The problem is that sometimes it seems to infinite loop, so yeah, no idea :D Just thought about scenarios how such an inifte loop could occur. All can be ruled out by attached backtraces: - isFinished never signaled - can be ruled out: If TextPageGenerationThread ran forever, TextPageGenerationThread::run would be on stack, but it's not. If the thread exited non-gracefully (i.e. abort()/SIGABRT), the whole program would have crashed, but it did not. - textpageGenerationFinished() never called - can be ruled out: It's connected to finished(), then same reasons as above apply. - textpageGenerationFinished() called, but QMutexLocker blocking forever - can be ruled out: textpageGenerationFinished is called in main thread via QueuedConnection, so the lock() would be visible on Thread 1 stack, and more, the mutex would also block the single shot timer, which is obviously not the case. After that I see no possibility for an infinite loop. How about generatePixmap simply being called very frequently in regular ways, then hitting the singleShot sometimes (but leaving it again), misleading us? I'll try to reproduce in kubuntu 19.10. Other ways of debugging could be to collect more data by means of a remotely executed gdb script or even a remote gdb session. But both have severe privacy/security implications, so I'm not sure if we could even suggest this to bug reporters. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 416656] PDF Launch Action allows to execute Mono executables
https://bugs.kde.org/show_bug.cgi?id=416656 --- Comment #5 from Albert Astals Cid --- You keep mentioning xdg-open but okular does not use xdg-open, can you try to trace who is invoking that for you? Oh wow, wait you're on Okular 1.3.3? that's more than 2 years old, maybe you can try to a distribution with a modern version of Okular and see if you can still reproduce the problem? -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 416157] okular crashed after some page changing in a ppt file
https://bugs.kde.org/show_bug.cgi?id=416157 Albert Astals Cid changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #4 from Albert Astals Cid --- Can we have that file? -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #18 from Albert Astals Cid --- (In reply to Tobias Deiminger from comment #17) > (In reply to Postix from comment #10) > > There are also a few lines with > > > generatePixmap > > Qt has a shortcut for QTimer::singleShot(msec = 0, ...), where they call > QMetaObject::invokeMethodImpl to trigger your lambda immediately via a > QueuedConnection plus one iteration through the event loop. > > So a callstack like yours > #n+1 QMetaObject::invokeMethodImpl > #n Okular::Generator::generatePixmap > ... > #n-m QCoreApplicationPrivate::sendPostedEvents > could indeed stem from a "text generation already finished but > mTextPageReady still false" endless loop, assuming the compiler has inlined > some calls for optimization. Note the "could", I see no definite proof yet. > > I generally agree with Albert that this issue is particularly hard to debug > without being able to reproduce it locally. The timer is not the problem, that timer gets triggered quite easily and doesn't infinite loop. The problem is that sometimes it seems to infinite loop, so yeah, no idea :D -- You are receiving this mail because: You are the assignee for the bug.
Re: Idea: Failing the build unless you explicitely chose which Okular UI you want to build
El dilluns, 27 de gener de 2020, a les 1:10:08 CET, Aleix Pol va escriure: > Hi Albert, > I'm unsure it's necessary to be this radical. IMHO, it's fine to just > not build okularkirigami if the dependencies don't match. And > viceversa. What if dependencies match both? Build both? That's exactly what I don't want, you end up with two .desktop files that claim to be Okular. Cheers, Albert > > Aleix > > On Sat, Jan 25, 2020 at 11:25 PM Albert Astals Cid wrote: > > > > Right now we build by default both the Desktop UI and the Mobile UI. > > > > In my opinion, for the user, that doesn't make sense, you either want one > > installed or the other installed, but not both. > > > > On the other hand, it makes lots of sense for CI and for developers, > > because you don't want to break the build of one while working on the other. > > > > My suggestion is to fail the build unless you specify which of the UI you > > want. > > > > So cmake . would fail and tell you something like: > > > > Please specify -DOKULAR_UI=Desktop|Mobile|Both > > > > And then users/distros would only build the one they want, and we devels/CI > > can still chose Both. > > > > What do you think? > > > > Cheers, > > Albert > > > > >
Re: Idea: Failing the build unless you explicitely chose which Okular UI you want to build
El dilluns, 27 de gener de 2020, a les 6:02:26 CET, Oliver Sander va escriure: > > So cmake . would fail and tell you something like: > > > > Please specify -DOKULAR_UI=Desktop|Mobile|Both > > I don't mind this flag at all, but I think the build should not fail without > it. > That's just one more hurdle to pass for newcomers. Can't newcomers read? Cheers, Albert > > Best, > Oliver > >
Re: Idea: Failing the build unless you explicitely chose which Okular UI you want to build
Hi Albert, I'm unsure it's necessary to be this radical. IMHO, it's fine to just not build okularkirigami if the dependencies don't match. And viceversa. Aleix On Sat, Jan 25, 2020 at 11:25 PM Albert Astals Cid wrote: > > Right now we build by default both the Desktop UI and the Mobile UI. > > In my opinion, for the user, that doesn't make sense, you either want one > installed or the other installed, but not both. > > On the other hand, it makes lots of sense for CI and for developers, because > you don't want to break the build of one while working on the other. > > My suggestion is to fail the build unless you specify which of the UI you > want. > > So cmake . would fail and tell you something like: > > Please specify -DOKULAR_UI=Desktop|Mobile|Both > > And then users/distros would only build the one they want, and we devels/CI > can still chose Both. > > What do you think? > > Cheers, > Albert > >
[okular] [Bug 416823] can no longer resize window with window actions
https://bugs.kde.org/show_bug.cgi?id=416823 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org --- Comment #1 from Albert Astals Cid --- Works fine for me -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 416815] errors in .desktop files
https://bugs.kde.org/show_bug.cgi?id=416815 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #1 from Albert Astals Cid --- You'll have to be a bit more precise on what's wrong, because it clearly says "Desktop file appears to be valid" -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 416656] PDF Launch Action allows to execute Mono executables
https://bugs.kde.org/show_bug.cgi?id=416656 --- Comment #4 from Jens Mueller --- I'm using Kali. Okular (xdg-open) does not allow you to *launch* Linux executables. It does however allow you to *open* files with a default application (e.g., a text like /etc/passwd file is opened with the default text editor; fair enough). Now, if we install mono (a dependency of bless), windows executable files are xdg-opened (via Okular) with mono and thereby can cause harm on Linux. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 416823] New: can no longer resize window with window actions
https://bugs.kde.org/show_bug.cgi?id=416823 Bug ID: 416823 Summary: can no longer resize window with window actions Product: okular Version: 1.9.1 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: wouterkay...@gmail.com Target Milestone: --- SUMMARY Since a recent update I can no longer resize the okular windows using alt and right click. This still works on all other windows and I can still move the window. This is a feauture enabled from window actions in the plasma settings. STEPS TO REPRODUCE 1. Open Okular 2. Try to resize using alt and right click OBSERVED RESULT The size of the window does not change. EXPECTED RESULT The window should change as all other windows do. SOFTWARE/OS VERSIONS Linux: 5.14.13-3-MANJARO KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.9 Qt Version: 5.14.0 ADDITIONAL INFORMATION -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 416157] okular crashed after some page changing in a ppt file
https://bugs.kde.org/show_bug.cgi?id=416157 MohammadReza Tohidi changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #3 from MohammadReza Tohidi --- It always happen just for this file, but the file is not corrupted and works well with other applications. -- You are receiving this mail because: You are the assignee for the bug.
D21971: Replace ToolAction by ToggleActionMenu
simgunz accepted this revision. simgunz added a comment. This revision is now accepted and ready to land. I compiled and it works. Looks good to me. @aacid Can you also have a look at this? REPOSITORY R223 Okular BRANCH create-configurable-toggleactionmenu REVISION DETAIL https://phabricator.kde.org/D21971 To: davidhurka, simgunz Cc: aacid, ngraham, simgunz, okular-devel, johnzh, andisa, siddharthmanthan, maguirre, fbampaloukas, joaonetto, kezik, tfella, darcyshen
[okular] [Bug 416815] New: errors in .desktop files
https://bugs.kde.org/show_bug.cgi?id=416815 Bug ID: 416815 Summary: errors in .desktop files Product: okular Version: 1.9.1 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: jasmi...@email.it Target Milestone: --- It seems there are issues with these .desktop files: /usr/share/applications/org.kde.mobile.okular_tiff.desktop /usr/share/applications/org.kde.mobile.okular_md.desktop /usr/share/applications/org.kde.mobile.okular_epub.desktop /usr/share/applications/org.kde.mobile.okular_djvu.desktop /usr/share/applications/org.kde.mobile.okular_chm.desktop They raise these warnings in synapse: Unable to create AppInfo for /usr/share/applications/org.kde.mobile.okular_tiff.desktop [WARN 09:32:49.802786] [desktop-file-service:200] Unable to create AppInfo for /usr/share/applications/org.kde.mobile.okular_md.desktop [WARN 09:32:49.803852] [desktop-file-service:200] Unable to create AppInfo for /usr/share/applications/org.kde.mobile.okular_epub.desktop [WARN 09:32:49.806062] [desktop-file-service:200] Unable to create AppInfo for /usr/share/applications/org.kde.mobile.okular_djvu.desktop [WARN 09:32:49.807085] [desktop-file-service:200] Unable to create AppInfo for /usr/share/applications/org.kde.mobile.okular_chm.desktop and these warnings with menulibre: "Unknown error. Desktop file appears to be valid." -- You are receiving this mail because: You are the assignee for the bug.
