[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Bug Janitor Service]

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

Bug Janitor Service  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #12 from Bug Janitor Service  ---
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Bug Janitor Service]

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

--- Comment #11 from Bug Janitor Service  ---
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Justin Zobel]

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

Justin Zobel  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 Status|REOPENED|NEEDSINFO

--- Comment #10 from Justin Zobel  ---
Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm
if this issue is still occurring or if this bug report can be marked as
resolved.

I have set the bug status to "needsinfo" pending your response, please change
back to "reported" or "resolved/worksforme" when you respond, thank you.

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

--- Comment #9 from RJVB  ---
> 
> https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for
> "backtrace" -- you can enable them for e.g. warnings exclusively.

It turns out that seting QT_MESSAGE_PATTERN from the code has the intended
effect, but
the %{backtrace} feature is only available on glib-based platforms. It also
doesn't provide very useful backtraces; no demangling, no filenames let alone
line numbers. A very simple test (qInfo() called from a function loggertest()
called from main() in an application called qlogging prints this:

?qlogging?|?qlogging?|__libc_start_main|?qlogging?

(even when built with -O0 -g)

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

--- Comment #8 from RJVB  ---
> What's the problem with running it under GDB?

Nothing, except that it takes minutes just to get the app to start (lldb is a
bit faster on my Mac) and it takes up gobs of additional RAM. That's OK when I
need actual debugger functionality like stepping through code or examining
variables. It's not feasible as a general runtime environment just to obtain a
backtrace. Esp. when you're rebuilding and restarting the app over an over
again to test tweaks like the standalone dockwidget (= how I spent much of my
yesterday).

My main reason for contributing is that I use the application (which is what I
try to do between patch revision procedures), and that it's a priori more
efficient to get my modifications upstreamed instead of maintaining a fork that
will inevitably become too much to handle.

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

--- Comment #7 from RJVB  ---
(In reply to Kevin Funk from comment #6)

> Yes. It told me you haven't fully understood the problem

I've understood (accepted) that the complexity of the plugin/toolview
architecture is in large part beyond me, just like you yourself have accepted
that the itemrepository issue is beyond you. I may be wrong about that, but
I've been looking on and off at the seemingly random aspect of the
documentation toolview for probably more than a year now (and I've been putting
up with it since v4.x).
And so what if we figure out where the creation comes from. We put the "don't
do this when shutting down" check there?

> hacks which inevitably may cause other crashes (i.e. when DocumentationView
> is being destructed again, trying to cleanup resources which were never
> initialized properly).

Seriously? There's only a default dtor, which doesn't know about anything
allocated dynamically through the ctor after the early return.

> > Nothing done in that ctor is crucial unless you use the instance, and 
> > that's not going to happen.
> 
> And you know that it isn't used based on...? How can you know it's not being
> used if you don't know where/when the class is being instantiated?

Ok, can you explain how a toolview could use the stuff it sets up for letting
the user interact with it after the program exit, if it cannot stop that
process?
I'll give it to you that the return was maybe a bit too early and should rather
exclude only the invocation of the initialisation method.
In practice I've seen the warning print a few times without any further
crashing.

I wouldn't have committed this without testing.

> https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for
> "backtrace" -- you can enable them for e.g. warnings exclusively.

That might be useful for critical messages, but still, Linux only apparently,
and I don't think you have this kind of control in the code just before a
specific log output. Or is there a way to do that?

> Please note that "drawn-out" review procedures are only necessary in
> "special cases".

They tend to get drawn out for other reasons too, ultimately leading to a core
dev "remote controlling" what boils down to one of his clones to write a piece
of code. It's just more efficient to skip the remote clone bit in those cases.

> Yes, or the original author could have at least committed that hunk
> separately, with a proper commit message explaining what this change does.

I am the original author ... can I take that as a green light to commit it?
(I kind of expected that Friedrich would commit this, as it's a fix for
something he introduced.)

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Kevin Funk]

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

--- Comment #6 from Kevin Funk  ---
> Have you read the ticket and commit message? I cannot reproduce the issue at 
> will either. It happens and *will* (always?) provoke a crash, but it does so 
> seemingly randomly. 

Yes. It told me you haven't fully understood the problem and you're adding
hacks which inevitably may cause other crashes (i.e. when DocumentationView is
being destructed again, trying to cleanup resources which were never
initialized properly).

> If you want to run each and every KDevelop session under a debugger with a 
> breakpoint set, be our guest (our as in everyone using the app). I don't have 
> the resources for that.

What's the problem with running it under GDB? Not having the resources for that
is not an excuse if you want to actively develop and file patches for a
project.

> I don't agree with your analysis in this case. There's no point in setting up 
> a DocumentationView when the application is exitting. 

I don't or didn't concur with that.

> Nothing done in that ctor is crucial unless you use the instance, and that's 
> not going to happen.

And you know that it isn't used based on...? How can you know it's not being
used if you don't know where/when the class is being instantiated?

> Alternatively, please provide a utility to print a backtrace in ICore or 
> wherever appropriate if there isn't already. I'll use that to determine where 
> the call comes from.

https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for "backtrace"
-- you can enable them for e.g. warnings exclusively.

> (Yes, I could write such a utility class myself but this time I'm going to 
> leave it to some of the powers that be who don't need drawn-out review 
> procedures.)

I see what you're hinting at.

Please note that "drawn-out" review procedures are only necessary in "special
cases". It's definitely not happing for the majority of incoming reviews for
KDevelop. The key point in not ending up with lengthy discussions in reviews is
a) having a good understanding of the problem at hand before even trying put up
patches for review, b) focusing on one issue at a time during discussions, c)
posting a patch where you have good confidence that it is the right fix to
begin with and not a series of obvious work-arounds.

> Oh, and you could have left the secondary fix in that commit.

Yes, or the original author could have at least committed that hunk separately,
with a proper commit message explaining what this change does.

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

--- Comment #5 from RJVB  ---
Created attachment 108328
  --> https://bugs.kde.org/attachment.cgi?id=108328=edit
debugging patch

I'll be running with this myself (in hope it's safe to call KMessageBox when
this issue occurs).

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

--- Comment #4 from RJVB  ---
(In reply to Kevin Funk from comment #2)
> Note: I can't reproduce your problem.

Could you please add something like this, at least? (Or use an ASSERT if you
run with those in place.)

--- a/kdevplatform/documentation/documentationview.cpp
+++ b/kdevplatform/documentation/documentationview.cpp
@@ -62,6 +62,10 @@ DocumentationView::DocumentationView(QWidget* parent,
ProvidersModel* model)

 mCurrent = mHistory.end();

+if (ICore::self()->shuttingDown()) {
+qFatal("DocumentationView created during shutdown");
+}
+
 setFocusProxy(mIdentifiers);

 QMetaObject::invokeMethod(this, "initialize", Qt::QueuedConnection);

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

--- Comment #3 from RJVB  ---
Have you read the ticket and commit message? I cannot reproduce the issue at
will either. It happens and *will* (always?) provoke a crash, but it does so
seemingly randomly. 

If you want to run each and every KDevelop session under a debugger with a
breakpoint set, be our guest (our as in everyone using the app). I don't have
the resources for that.

I don't agree with your analysis in this case. There's no point in setting up a
DocumentationView when the application is exitting. Nothing done in that ctor
is crucial unless you use the instance, and that's not going to happen.

Alternatively, please provide a utility to print a backtrace in ICore or
wherever appropriate if there isn't already. I'll use that to determine where
the call comes from.
(Yes, I could write such a utility class myself but this time I'm going to
leave it to some of the powers that be who don't need drawn-out review
procedures.)

Oh, and you could have left the secondary fix in that commit.

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Kevin Funk]

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

Kevin Funk  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #2 from Kevin Funk  ---
Note: I can't reproduce your problem.

Tips to solve this correctly:
Please put a breakpoint on "DocumentationView::DocumentationView(QWidget*
parent, ProvidersModel* model)" and check where/when it is being called during
shutdown. Post the backtrace, please.

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[RJVB]

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

RJVB  changed:

   What|Removed |Added

  Latest Commit||https://commits.kde.org/kde
   ||velop/4b4806d02ad099b5ef306
   ||2286a1dfdef21195ee4
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from RJVB  ---
Git commit 4b4806d02ad099b5ef3062286a1dfdef21195ee4 by R.J.V. Bertin.
Committed on 12/10/2017 at 19:02.
Pushed by rjvbb into branch '5.2'.

Don't set up DocumentationViews when shutting down

In rare situations a DocumentationView can be created when shutting
down, which can lead to race conditions and crashing. Prevent this by
returning early from the class ctor when shutdown is in progress.

In addition, prevent errors from QWidget::setTabOrder() by checking its
input arguments.

M  +8-1kdevplatform/documentation/documentationview.cpp

https://commits.kde.org/kdevelop/4b4806d02ad099b5ef3062286a1dfdef21195ee4

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Kevin Funk]

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

Kevin Funk  changed:

   What|Removed |Added

  Component|general |Documentation viewer

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

[kdevelop] [Bug 385640] KDevelop: DocumentationView causing crash on exit [DocumentationView::initialize]

[Kevin Funk]

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

Kevin Funk  changed:

   What|Removed |Added

Summary|KDevelop: DocumentationView |KDevelop: DocumentationView
   |causing crash on exit   |causing crash on exit
   ||[DocumentationView::initial
   ||ize]

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