https://bugs.kde.org/show_bug.cgi?id=490527

            Bug ID: 490527
           Summary: Default-enabled gdb symbols when submitting crash
                    reports eats RAM and causes a system lockup
    Classification: Plasma
           Product: plasmashell
           Version: 6.1.2
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: generic-crash
          Assignee: plasma-b...@kde.org
          Reporter: eamonn...@protonmail.com
  Target Milestone: 1.0

SUMMARY
When waking my computer from sleep, Plasma consistently shows the crash
reporter. When I try to report the crash, the GDB checkbox is already enabled,
and the crash reporter tries to report the bug. Presumably it is waiting on
getting the symbols from GDB to submit as part of the crash report. However in
doing this, the GDB process will keep eating ram until my system locks up.
Disabling the GDB checkbox doesn't resolve the problem, the process continues
and will eat RAM until a system lockup.

This can take a while as the memory consumption increases gradually. I'm not
sure quite how long it takes, maybe approximately 10 minutes, but the first
time I encountered this was when I had woken my computer from sleep, tried to
submit the crash report, and then realised a bit too late that my system had a
*lot* of memory used with a widget I have in one of my panels. The next time it
happened I noticed it was GDB eating the memory, and in the Crash Reporter I
saw that there was a checkbox for the debug symbols. But disabling this didn't
appear to do anything.

I understand the requirement for symbols and why they're enabled by default,
but unfortunately in some cases it can exhaust all system RAM. I'm not sure
what Plasma could do about this. This could be entirely wrong, but perhaps this
crash is a large core component of Plasma crashing, and fetching the symbols
just requires a *lot* of memory. Maybe symbols should be disabled by default if
Plasma can detect certain components have crashed, or on systems with lower
memory?

I have 32GB RAM on my Desktop and PC, and although this is more-or-less
standard for modern hardware, users with older hardware (even moreso hardware
that cannot be upgraded) may not have the luxury of more than 16GB RAM. And
some users may not even check the system monitor to see that GDB is the culprit
eating RAM overtime, their system may just lock up suddenly. Or if they're
watching the Crash Reporter they may not realise why it is taking so long.

STEPS TO REPRODUCE
1. Produce a crash and get the Crash Reporter, in my case, waking my Desktop PC
from sleep will always show this, but my laptop does not show this. Perhaps it
needs to be something like the Plasma session crashing entirely?
2. Report the crash, including debug symbols should be enabled by default.
3. GDB will gradually keep consuming memory until the system locks up.

OBSERVED RESULT
Crash Reporter's option to include debug symbols can cause the system to
exhaust all available memory and lock up.

EXPECTED RESULT
That's a tricky one to answer without simply saying "memory shouldn't be
exhausted" but this is a direct product of GDB, and I would imagine including
those symbols is pretty much required for tracking down nasty bugs without
fumbling in the dark (or I believe so anyway, I'm not super familiar with C++).

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.9.9 Linux Zen
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
To clarify, this is not a report for the crash when waking from sleep, this is
a bug report for the Crash Reporter firing GDB by default (again,
understandably!) but in this case it will eat RAM until the system halts.
Waking from sleep is just the crash that happens to trigger GDB eating a ton of
memory.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to