info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Okular locked up my system and left no evidence
2 views
Skip to first unread message
Borden
Feb 10, 2023, 1:10:03 AM2/10/23
to
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.
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.
Borden
Feb 10, 2023, 1:50:03 AM2/10/23
to
10 Feb 2023, 01:03 by bord...@tutanota.com:
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!!!
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!!!
Alex DEKKER
Feb 10, 2023, 6:00:03 AM2/10/23
to
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.
>
> 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!!!
>
>
alexd
Diederik de Haas
Feb 10, 2023, 11:00:03 AM2/10/23
to
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:
> which may be more productive.
- 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 | ..."
Borden
May 2, 2023, 4:10:03 AM5/2/23
to
10 Feb 2023, 10:53 by didi....@cknow.org:
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?
0 new messages