Created attachment 125381 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.

Created attachment 130510 [details]
New crash information added by DrKonqi

kdevelop (5.5.40) using Qt 5.14.2

- What I was doing when the application crashed:

I changed a class method declaration and then clicked on the suggested solution to update the method signature in the implementation file which lead to this crash. 

Looking at `plugins/clang/codegen/adaptsignatureaction.cpp:83` the crash seems to happen because of a failed assert in `ENSURE_CHAIN_NOT_LOCKED`, i.e. because the DU chain is locked for some reason.

-- Backtrace (Reduced):
#4  0x00007fd7b59c0f47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5  0x00007fd7b59c28b1 in __GI_abort () at abort.c:79
#6  0x00007fd7b618a68b in qt_message_fatal (context=..., message=<synthetic pointer>...) at global/qlogging.cpp:1914
#7  0x00007fd7b618a68b in QMessageLogger::fatal(char const*, ...) const (this=this@entry=0x7ffd9e94d860, msg=msg@entry=0x7fd7b648a9a0 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:893
#8  0x00007fd7b6189e81 in qt_assert(char const*, char const*, int) (assertion=<optimized out>, file=<optimized out>, line=<optimized out>) at global/qglobal.cpp:3342

Created attachment 142580 [details]
New crash information added by DrKonqi

kdevelop (5.6.40) using Qt 5.15.2

- What I was doing when the application crashed:

I pressed "update signature" after changing the signature of a constructor in the header file, then KDevelop crashed.

-- Backtrace (Reduced):
#7  0x00007fb65ad5a85c in qt_assert_x(char const*, char const*, char const*, int) () at /lib64/libQt5Core.so.5
#8  0x00007fb5f863b51b in AdaptSignatureAction::execute() (this=0x2da76d0) at /home/benjamin/Applications/kdevelop/plugins/clang/codegen/adaptsignatureaction.cpp:83
#9  0x00007fb65df82c35 in KDevelop::ProblemNavigationContext::executeAction(int) (this=0x48e0bf0, index=0) at /home/benjamin/Applications/kdevelop/kdevplatform/language/duchain/navigation/problemnavigationcontext.cpp:258
#10 0x00007fb65df82b5f in KDevelop::ProblemNavigationContext::executeKeyAction(QString const&) (this=0x48e0bf0, key=...) at /home/benjamin/Applications/kdevelop/kdevplatform/language/duchain/navigation/problemnavigationcontext.cpp:243
#11 0x00007fb65df89bcc in KDevelop::AbstractNavigationContext::execute(KDevelop::NavigationAction const&) (this=0x48e0bf0, action=...) at /home/benjamin/Applications/kdevelop/kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:183

Hmm, the problem seems to be that the DUChain is readlocked in
`AbstractNavigationWidgetPrivate::anchorClicked`. However, that
lock was added there to fix bug 386901 so it cannot just be removed.

Probably the solution is to move the lock further down the call chain
for bug 386901, though its not completely clear to me where...

The call chain triggering bug 386901 without the lock acquired in `anchorClicked`
looks as follows (from outer caller to inner caller):


in KDevelop::AbstractNavigationWidgetPrivate::anchorClicked at kdevplatform/language/duchain/navigation/abstractnavigationwidget.cpp:285

in KDevelop::AbstractNavigationContext::acceptLink at kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:487

in KDevelop::AbstractNavigationContext::execute at kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:201

in KDevelop::AbstractNavigationContext::registerChild at kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:281

in ClangDUContext<KDevelop::TopDUContext, 140>::createNavigationWidget at plugins/clang/duchain/clangducontext.cpp:46

in ClangNavigationWidget::ClangNavigationWidget at plugins/clang/duchain/navigationwidget.cpp:98

in DeclarationNavigationContext::AbstractDeclarationNavigationContext at plugins/clang/duchain/navigationwidget.cpp:38

in AbstractDeclarationNavigationContext::AbstractDeclarationNavigationContext at kdevplatform/language/duchain/navigation/abstractdeclarationnavigationcontext.cpp:67

in KDevelop::FunctionDefinition::declaration at kdevplatform/language/duchain/functiondefinition.cpp:52


where an assert is hit in the `ENSURE_CAN_READ` macro.

(source code locations from master at 5b8c6afe6f1bdfc)

A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/277

*** Bug 401221 has been marked as a duplicate of this bug. ***

Git commit a947074f0872ad3245b8c73679143998a88e3753 by Igor Kushnir, on behalf of Jonathan L. Verner.
Committed on 01/05/2022 at 12:56.
Pushed by igorkushnir into branch 'release/22.04'.

Fix a crash in the "update signature action".

The problem seems to be that the DUChain is readlocked in
`AbstractNavigationWidgetPrivate::anchorClicked` (see also [2]),
which then proceeds through the following (backtrace-like) call chain

  #9  AdaptSignatureAction::execute()
      (at plugins/clang/codegen/adaptsignatureaction.cpp:83)
  #10 ProblemNavigationContext::executeAction(int)
(at kdevplatform/language/duchain/navigation
problemnavigationcontext.cpp:258)
  #11 ProblemNavigationContext::executeKeyAction(QString const&)
(at
kdevplatform/language/duchain/navigation/problemnavigationcontext.cpp:243)
const&)
(at
kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:183)
  #13 AbstractNavigationContext::acceptLink(QString const&)
(at
kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:487)
  #14 AbstractNavigationWidgetPrivate::anchorClicked

which ends at

  plugins/clang/codegen/adaptsignatureaction.cpp:83

with an `ENSURE_CHAIN_NOT_LOCKED` macro, which asserts.

However, the lock in `anchorClicked` was added there in
commit ff72bc32 to fix bug 386901 ([1]) so it cannot
just be removed. The callchain triggering the 386901 bug looks
as follows:

  #0 FunctionDefinition::declaration
     (at kdevplatform/language/duchain/functiondefinition.cpp:52)
  #1 FunctionDefinition::declaration
     (at kdevplatform/language/duchain/functiondefinition.cpp:52)
AbstractDeclarationNavigationContext::AbstractDeclarationNavigationContext
(at
kdevplatform/language/duchain/navigation/abstractdeclarationnavigationcontext.cpp:67)
  #3 DeclarationNavigationContext::AbstractDeclarationNavigationContext
     (at plugins/clang/duchain/navigationwidget.cpp:38)
  #4 ClangNavigationWidget::ClangNavigationWidget
     (at plugins/clang/duchain/navigationwidget.cpp:98)
  #5 ClangDUContext<KDevelop::TopDUContext, 140>::createNavigationWidget
     (at plugins/clang/duchain/clangducontext.cpp:46)
  #6 AbstractNavigationContext::registerChild
(at
kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:281)
  #7 AbstractNavigationContext::execute
(at
kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:201)
  #8 AbstractNavigationContext::acceptLink
(at
kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp:487)
  #9 AbstractNavigationWidgetPrivate::anchorClicked
(at
kdevplatform/language/duchain/navigation/abstractnavigationwidget.cpp:285)

which hits an assert at

   kdevplatform/language/duchain/functiondefinition.cpp:52

in the `ENSURE_CAN_READ` macro.

This commit moves the lock from `anchorClicked` into
`AbstractNavigationContext::registerChild`, which is the
last opportunity for a lock before a language-plugin specific
method is called (so that the bug does not reappear in
other language plugins).

References

[1] https://bugs.kde.org/show_bug.cgi?id=386901
[2] https://phabricator.kde.org/D22182
Related: bug 358787
FIXED-IN: 5.8.220401

M  +11   -0    kdevplatform/language/duchain/navigation/abstractnavigationcontext.cpp
M  +0    -2    kdevplatform/language/duchain/navigation/abstractnavigationwidget.cpp

https://invent.kde.org/kdevelop/kdevelop/commit/a947074f0872ad3245b8c73679143998a88e3753