Bug 436339 - Kdevelop gdb integration is extremely slow
Summary: Kdevelop gdb integration is extremely slow
Status: CONFIRMED
Alias: None
Product: kdevelop
Classification: Applications
Component: CPP Debugger (show other bugs)
Version: 5.5.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-29 07:10 UTC by Mattia Basaglia
Modified: 2021-10-19 17:52 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mattia Basaglia 2021-04-29 07:10:20 UTC
SUMMARY

Not always, but often enough, debugging is very slow with kdevelop.

Symptoms include:

* taking several seconds before "step over" and similar take effect
* variable values not updating / loading in their tree view
* the "GDB cmd" textbox being grayed out

each of the above can take a long time to solve (like 20 seconds or so) to the point of being unusable.

The slow down isn't consistent, sometimes everything works, sometimes it takes a handful of seconds (which is annoying but manageable), sometimes it takes a very long time, which makes debugging unusable.

This issue only happens with Kdevelop, if I use gdb from the terminal it works fine.
I have a fairly powerful computer so that isn't an issue.


SOFTWARE/OS VERSIONS
Operating System: Kubuntu 20.10
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.14.2
Kernel Version: 5.8.0-50-generic
OS Type: 64-bit
Processors: 8 × AMD FX(tm)-8320 Eight-Core Processor
Memory: 23.5 GiB of RAM
Graphics Processor: AMD Radeon ™ RX 470 Graphics

GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Comment 1 Igor Kushnir 2021-04-29 09:47:15 UTC
I have experienced similar slowdown while debugging several months ago. Haven't debugged much recently, so not sure if this affects the current KDevelop master.
Comment 2 Igor Kushnir 2021-05-21 12:12:34 UTC
Just hit this bug while debugging. So it affects an almost latest KDevelop master.
Comment 3 Mattia Basaglia 2021-05-27 15:18:48 UTC
I think it's related to the "variables" pane, if I collapse "Locals" it's a bit faster at stepping than when it's expanded.
Comment 4 Bug Janitor Service 2021-10-19 14:18:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/268
Comment 5 Igor Kushnir 2021-10-19 17:52:17 UTC
Git commit 7b302184fcbd774b61edef3c40a7fb0ff672cf42 by Igor Kushnir.
Committed on 19/10/2021 at 14:13.
Pushed by mwolff into branch 'master'.

GDB printers: don't call QUrl::toString() when d is null

A default-constructed QUrl is invalid, its d-pointer is null. After
QUrlPrinter repeatedly dereferences the null pointer, eventually (at the
line of the first QStringPrinter call on my system) an exception is
raised and QUrl::toString() is called via gdb.parse_and_eval() in a
fallback path. The fallback path turns out to be extremely slow:
hovering the mouse pointer over a default-constructed QUrl variable
while debugging occupies GDB for about 15 seconds on my system.
By contrast, GDB computes the value of a valid QUrl in about a second.
Returning early when the d-pointer is null makes printing an invalid
QUrl about as fast as a valid one.

Without the added early return, "" is displayed in KDevelop's debugging
UI as an invalid QUrl variable's value, even though valid QUrl values
are not quoted. When QUrlPrinter early-returns "", an empty space
(not "") is displayed, which is indistinguishable from a not yet
computed value. Returning '""' would preserve the current "" value in
the UI. But Qt Creator's debugging UI displays <invalid> in this case,
which seems a better fit, so let us follow suit.

M  +2    -0    plugins/debuggercommon/tests/debuggees/qurl.cpp
M  +2    -0    plugins/gdb/printers/qt.py
M  +8    -1    plugins/gdb/unittests/test_gdbprinters.cpp

https://invent.kde.org/kdevelop/kdevelop/commit/7b302184fcbd774b61edef3c40a7fb0ff672cf42