Bug 427246

Summary: SIGTRAP/SIGSEGV while running any version of KDevelop under GDB after a recent system update
Product: [Applications] kdevelop Reporter: Igor Kushnir <igorkuo>
Component: generalAssignee: kdevelop-bugs-null
Status: RESOLVED UPSTREAM    
Severity: crash CC: mail, soos.mate
Priority: NOR    
Version: git master   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Igor Kushnir 2020-10-02 13:19:19 UTC 
SUMMARY
Since the yesterday's large Manjaro stable update, debugging KDevelop from KDevelop or from GDB command line results in multiple SIGTRAP and/or SIGSEGV signals.

STEPS TO REPRODUCE
1. source /path/to/prefix.sh (to set QT_PLUGIN_PATH and other environment variables)
2. gdb ./bin/kdevelop
3. (gdb) start -s 'test kdevelop5 session'
4. (gdb) c

OBSERVED RESULT
Thread 26 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 44850]
0x00007ffff7fd575b in dl_main () from /lib64/ld-linux-x86-64.so.2
(gdb) thread apply all bt

Thread 26 (LWP 44850):
#0  0x00007ffff7fd575b in dl_main () from /lib64/ld-linux-x86-64.so.2
#1  0x00007ffff7feb992 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7fd2ff1 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7fd2098 in _start () from /lib64/ld-linux-x86-64.so.2
#4  0x0000000000000003 in ?? ()
#5  0x00007fffffffe89b in ?? ()
#6  0x00007fffffffe8aa in ?? ()
#7  0x00007fffffffe8b1 in ?? ()
#8  0x0000000000000000 in ?? ()

EXPECTED RESULT
KDevelop runs normally without SIGTRAP or SIGSEGV signals.

SOFTWARE/OS VERSIONS
Manjaro GNU/Linux, Xfce
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1

ADDITIONAL INFORMATION
When I debug KDevelop from KDevelop, I usually get SIGTRAP signals instead of SIGSEGV and can sometimes temporarily work them around by setting a temporary hardware breakpoint at the SIGTRAP address:
*** Program received signal SIGTRAP (Trace/breakpoint trap) ***(gdb) 28thread apply all bt

Thread 33 (LWP 45790):
#0 0x00007f8ee90c38fe in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#1 0x00007f8ee4a30088 in ?? ()
#2 0x00007ffde5e39340 in ?? ()
#3 0x00007ffde5e39440 in ?? ()
#4 0x00007f8ee90c3320 in ?? () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffde5e39360 in ?? ()
#6 0x00005571d3123ca0 in ?? ()
#7 0x00007f8ee4ab7a00 in ?? ()
#8 0x00007ffde5e39340 in ?? ()
#9 0x00007ffde5e3924c in ?? ()
#10 0x0000000080001001 in ?? ()
#11 0xb020296fce29d303 in ?? ()
#12 0xffffffffffffff68 in ?? ()
#13 0x0000000000000003 in ?? ()
#14 0x00007f8ee50ac9a9 in ?? ()
#15 0xfffffffffffffffe in ?? ()
#16 0xb020296fcce9d303 in ?? ()
#17 0xb0c62beee84bd303 in ?? ()
#18 0x0000557100000000 in ?? ()
#19 0x00005571d39d04d0 in ?? ()
#20 0x0000000000000003 in ?? ()
#21 0x00007f8ee512430b in ?? ()
#22 0x0000000000000003 in ?? ()
#23 0x00005571d39d04d0 in ?? ()
#24 0x0000000000000000 in ?? ()

Thread 32 (LWP 45948):
#0 0x00007f8e6b72be4b in ?? ()
#1 0x00007f8e5400c858 in ?? ()
#2 0x00007f8e5400c890 in ?? ()
#3 0x00007f8e5400c858 in ?? ()
#4 0x00007f8e6b72c085 in ?? ()
#5 0x00007f8e5400c858 in ?? ()
#6 0x00007f8e6b72c19a in ?? ()
#7 0x00007f8e54003e00 in ?? ()
#8 0x00007f8e6b71e793 in ?? ()
#9 0x0000000001000000 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 30 (LWP 45946):
#0 0x00007f8e6b67ee98 in ?? ()
#1 0x000000000000000a in ?? ()
#2 0x00007f8e6b729850 in ?? ()
#3 0x00007f8e505e1ea0 in ?? ()
#4 0x00007f8e6b72b939 in ?? ()
#5 0x00007f8e505e0248 in ?? ()
#6 0x00007f8e6acd44c0 in ?? ()
#7 0x00007f8e6acd44b8 in ?? ()
#8 0x0000000000000000 in ?? ()

Thread 29 (LWP 45943):
#0 0x00007f8ee49e672b in ?? ()
#1 0x00007f8e5c013060 in ?? ()
#2 0x0000002ad2313d00 in ?? ()
#3 0x00007f8e5c013420 in ?? ()
#4 0x00007f8e6b6e9e3e in ?? ()
#5 0x00007f8e5c013110 in ?? ()
#6 0x00007f8e5c013288 in ?? ()
#7 0x00007f8e5c013110 in ?? ()
#8 0x00007f8e6b6e7fdf in ?? ()
#9 0x0000000000000000 in ?? ()
28^done
(gdb) 31f 0
#0 0x00007f8ee90c38fe in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
31^done
(gdb) 34thbreak *0x00007f8ee90c38fe
Hardware assisted breakpoint 1 at 0x7f8ee90c38fe
34^done
(gdb) 37c
Continuing.
37^running
(gdb) 42c
Continuing.
42^running

After these commands KDevelop usually runs normally until a code breakpoint is hit, at which point the debugged instance receives SIGTRAP/SIGSEGV signals and eventually crashes.

I tried debugging other applications - kate, audacious, flacon, drkonqi - and none of them crashes under GDB.

FAILED WORKAROUNDS
1. Older kernel: the same crash happens under linux57 (5.7.19) built on 2020-09-09.
2. Different KDevelop version: the same crash happens with several of my older builds and fresh ones too.
3. KDevelop Release build: the same crash happens in my system-installed version built more than a month ago.
4. Attach to a running KDevelop instance: it appears to run OK until a code breakpoint is hit, at which point the debugged instance receives SIGTRAP/SIGSEGV signals and eventually crashes.
5. I have tried workarounds described in answers to the following Stack Overflow questions, but they help only temporarily:
https://stackoverflow.com/questions/9837594/sigtrap-despite-no-set-breakpoints-hidden-hardware-breakpoint
https://stackoverflow.com/questions/15667795/how-can-i-make-gdb-stop-at-sigtrap-only-at-breakpoints

WORKAROUNDS
1. Disabling all KDevelop plugins prevents a crash, but renders KDevelop useless. TODO: try to disable only some/most of them. Could there be a problem in one or more plugins? Or in the long time it takes KDevelop to load many plugins under debugger?

FUTURE TESTS
1. Downgrade to Qt 5.15.0
2. Downgrade to KF 5.73.0
3. Some other package downgrade. Arch users who upgrade their system often might have narrowed down the list of upgraded packages...

I thought that the issue was specific to my system, but noticed that others experience the same problem as mentioned in Bug 427227.
Comment 1 Igor Kushnir 2020-10-02 20:21:31 UTC 
FAILED WORKAROUND
Add the following two lines to /etc/security/limits.conf and reboot:
*           	hard	nofile		100000	# necessary for KDevelop
*           	soft	nofile		100000	# necessary for KDevelop
This workaround does not change anything.

INADEQUATE WORKAROUND
Narrowed down the plugins that must be disabled in ~/.local/share/kdevelop/sessions/{<session-id>}/sessionrc to enable launching, hitting breakpoints in the KDevelop source code and exiting KDevelop without crashes: KDevCMakeDocumentation, kdevfilemanager, kdevqthelp (I have kdevperforce and katectagsplugin disabled too, but not sure if that's necessary). In addition, I had to force-disable kdevclangsupport plugin via `export KDEV_DISABLE_PLUGINS=kdevclangsupport`. Even without these essential plugins, opening a project triggers the signals and crashes.

FIX
This is a known Qt 5.15.1 bug: QTBUG-86319 (I found a duplicate of this bug by searching for "SIGTRAP" on the Qt bug tracker). The corresponding Arch Linux bug: https://bugs.archlinux.org/task/68001. I applied the fix for the Qt bug from https://codereview.qt-project.org/c/qt/qtbase/+/314049 and the signals and crashes are gone!

The fix will be included in Qt 5.15.2. In the meantime, it would be useful if the qt5-base Arch Linux package included the patch to spare developers from manually applying the fix after each qt5-base pkgrel update. @{Arch Linux users affected by this bug}, please create an issue on the Arch bug tracker or reopen FS#68001 (closed because this turned out to be not a GDB issue) and request the qt5-base patch.
Comment 2 Francis Herne 2020-10-02 20:59:55 UTC 
I have filed an Arch ticket: https://bugs.archlinux.org/task/68080

I don't think there's anything else we can do for now, so closing this. Will comment if the Arch maintainers respond.

As I mentioned on the other bug, one workaround is to start KDevelop and then use `gdb --pid=<whatever>`.
Comment 3 Igor Kushnir 2020-10-02 21:11:54 UTC 
(In reply to Francis Herne from comment #2)
> As I mentioned on the other bug, one workaround is to start KDevelop and
> then use `gdb --pid=<whatever>`.
I haven't tried this workaround from the command line, but attaching to a KDevelop process from another KDevelop instance/session didn't work well for me: once a code breakpoint was hit, the debugged instance received SIGTRAP/SIGSEGV signals and eventually crashed. With the patched Qt attaching from KDevelop works fine.
Comment 4 Francis Herne 2020-10-02 23:45:44 UTC 
Arch just backported the relevant fix in qt5-base 5.15.1-3. I've installed this and gdb works again.

Thanks Igor for finding the relevant upstream bug.