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

            Bug ID: 427246
           Summary: SIGTRAP/SIGSEGV while running any version of KDevelop
                    under GDB after a recent system update
           Product: kdevelop
           Version: git master
          Platform: Compiled Sources
                OS: Linux
            Status: REPORTED
          Severity: crash
          Priority: NOR
         Component: general
          Assignee: kdevelop-bugs-n...@kde.org
          Reporter: igor...@gmail.com
  Target Milestone: ---

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.

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

Reply via email to