1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.KDE

  • Okular locked up my system and left no evidence

    From Borden@21:1/5 to All on Fri Feb 10 07:10:01 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Borden@21:1/5 to All on Fri Feb 10 07:50:01 2023
    10 Feb 2023, 01:03 by borden_c@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!!!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alex DEKKER@21:1/5 to Borden on Fri Feb 10 12:00:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diederik de Haas@21:1/5 to Borden on Fri Feb 10 16:53:28 2023
    Copy: debian-kde@lists.debian.org (Debian Kde)

    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 | ..."
    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY+ZoeAAKCRDXblvOeH7b bqsEAQD2e75AIi/+2JtpAh8/B1UpjFbAtcysC0hkrm8f5TIgZAEA1ailO5rVEJkw KugYUuD9jVBshUHqeld+am9GrVaBvQA=
    =zLdP
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Borden@21:1/5 to All on Tue May 2 10:10:01 2023
    10 Feb 2023, 10:53 by didi.debian@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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)