Re: Okular locked up my system and left no evidence
10 Feb 2023, 10:53 by didi.deb...@cknow.org: > On Friday, 10 February 2023 07:46:36 CET Borden wrote: > >> which may be more productive. >> > > What would be even more productive is the following: > - log in remotely before doing another test and open a screen/tmux session > (or > open several distinct remote logins) and start: > - htop > - tail -f ~/.xsession-errors > - journalctl --user -b -f > - any other program which may be useful IYO > > Then start okular from Konsole, but give it a lower priority with `nice` (and > `ionice`). Possibly useful to `tee` the Konsole output to a file too. > If it behaves so bad again, you should be able to kill okular (f.e.). > > And then file a bug report with a sample PDF as Alex suggested and provide > any > info you obtained which may help to solve this issue. > > You didn't specify which Debian and Okular version you had this issue with. > In case of Testing or Sid, the "/topic" from #debian-next comes to mind: > "testing → bookworm | you may need to debug sometimes | ..." > Sorry for the delayed response, and thank you for the suggestions. Unfortunately, I couldn't file a bug report because the PDF in question had very sensitive information, so I ended up just working around the problem in Windows. I think the point of my complaint got lost. It's not so much that Okular had a major, semi-reproducable bug. It's that, in 2023, userland software still cripples systems. I would hope that, by now, a kernel can determine whether an application is being too greedy and stop marshalling resources to it to the point of a total lock-up. It's analogous to how the Ford Pinto could explode if it got rear-ended. Yes, I'm sure someone nursing second-degree burns after a collision would benefit from better adjusted mirrors and regular circle checks while driving. However, the real issue is that no car should catch fire in a fender-bender. And that's what I want to know: how do I stop Linux and KDE from exploding during an otherwise minor mishap?
Re: Okular locked up my system and left no evidence
On Friday, 10 February 2023 07:46:36 CET Borden wrote: > which may be more productive. What would be even more productive is the following: - log in remotely before doing another test and open a screen/tmux session (or open several distinct remote logins) and start: - htop - tail -f ~/.xsession-errors - journalctl --user -b -f - any other program which may be useful IYO Then start okular from Konsole, but give it a lower priority with `nice` (and `ionice`). Possibly useful to `tee` the Konsole output to a file too. If it behaves so bad again, you should be able to kill okular (f.e.). And then file a bug report with a sample PDF as Alex suggested and provide any info you obtained which may help to solve this issue. You didn't specify which Debian and Okular version you had this issue with. In case of Testing or Sid, the "/topic" from #debian-next comes to mind: "testing → bookworm | you may need to debug sometimes | ..." signature.asc Description: This is a digitally signed message part.
Re: Okular locked up my system and left no evidence
On 10/02/2023 06:46, Borden wrote: There's a grave problem with how Okular processes PDF forms. Simple, short-answer text entry has ballooned a simple 1 MB file into a 1.2 GB file. This would explain (but not excuse) the excessive CPU and hard-drive usage. It probably also maxed out the RAM and caused the system to freeze. Workaround: avoid using Okular to complete PDF forms at all costs!!! I'm sure a sample PDF attached to the bug report would be appreciated. alexd
Re: Okular locked up my system and left no evidence
10 Feb 2023, 01:03 by borde...@tutanota.com: > I was trying to fill out a PDF form on Okular and my system started crawling > to halt on text fields until it locked up completely. SSD stayed solid on (so > God knows how many write cycles it gluttoned), fan went into overdrive trying > to keep the circuitry from frying, and the computer completely froze. I > couldn't even SSH in to shut down programs because my frozen computer > couldn't spare any resources to authenticate remote access. The only log > entries indicating that something was amiss was: > > boinc[1409]: 10-Feb-2023 00:22:44 [---] Suspending computation - CPU is busy > boinc[1409]: 10-Feb-2023 00:22:57 [---] Resuming computation > > Followed by a 10-minute gap in all logs until I hard-rebooted the system. > > So unless I missed something in one of the logs, there's nothing anyone can > do about this other than note for posterity that KDE and Linux still have > systemic design flaws. Rogue apps can still cripple the system without > leaving any evidence whatsoever of what went wrong. And until it leaves > evidence, there's no way to identify the bugs. Just frustrated users and lost > data when you can't save what you're working on. > > Maybe a doctoral student is working on these design issues so this doesn't > happen. If not, there should be. > > Vent over. Thank you for reading. > Supplemental to rant, which may be more productive. There's a grave problem with how Okular processes PDF forms. Simple, short-answer text entry has ballooned a simple 1 MB file into a 1.2 GB file. This would explain (but not excuse) the excessive CPU and hard-drive usage. It probably also maxed out the RAM and caused the system to freeze. Workaround: avoid using Okular to complete PDF forms at all costs!!!
Okular locked up my system and left no evidence
I was trying to fill out a PDF form on Okular and my system started crawling to halt on text fields until it locked up completely. SSD stayed solid on (so God knows how many write cycles it gluttoned), fan went into overdrive trying to keep the circuitry from frying, and the computer completely froze. I couldn't even SSH in to shut down programs because my frozen computer couldn't spare any resources to authenticate remote access. The only log entries indicating that something was amiss was: boinc[1409]: 10-Feb-2023 00:22:44 [---] Suspending computation - CPU is busy boinc[1409]: 10-Feb-2023 00:22:57 [---] Resuming computation Followed by a 10-minute gap in all logs until I hard-rebooted the system. So unless I missed something in one of the logs, there's nothing anyone can do about this other than note for posterity that KDE and Linux still have systemic design flaws. Rogue apps can still cripple the system without leaving any evidence whatsoever of what went wrong. And until it leaves evidence, there's no way to identify the bugs. Just frustrated users and lost data when you can't save what you're working on. Maybe a doctoral student is working on these design issues so this doesn't happen. If not, there should be. Vent over. Thank you for reading.
