There are a lot of changesets outstanding across many different bug reports.  In order to break the logjam, I am starting by committing the patch in comment #13.

Hopefully Dan can figure out how that causes a refresh in the other linked bug reports.

Marking as fixed and closing this report.

@Dan: Then this is the reason, I have Qt 5.5.1

Can Dan's patch be applied then? I can not test, because i could not reproduce the issue in Unity or KDE.

What is the status of this changeset?  It sounds as though it has stopped the crash.  Does it need testing on Windows/other OS's?  It's short and solves a crash, so perhaps placing it on dev branch is the best way to go.  That way I can update the bigger patch in Bug #53276 and address the Qt bug for 5.6.1 through 5.7.0.

Philip, my understanding is that release candidates are started from the "stable" branch as to avoid more experimental and not-so-stable code from finding its way into a release.  When there is something that needs to be fixed in both "stable" and "dev", first the "stable" branch is patched then periodically Rik will merge "stable" with "dev" which brings those fixes on "stable" into "dev", and the merged branch continues on as the "dev" branch.

That's the general approach.  An alternative model is to apply the patch to both branches separately...or another alternative is to apply branches to dev and then cherry-pick the changes, but those approaches seem more prone to confusion.

@Philip: Yes, the bug was before 4.4, so it is now also in the stable branch and it has to be fixed there. The default branch was merged to stable with http://hg.savannah.gnu.org/hgweb/octave/rev/4e5d39c1b680 and from this cset on, stable is merged into default. A fix in the default branch would not fix it in 4.4

@Philip:

comment #14: ... starting from current dev tip ...

This patch should be applied for the stable branch (version 4.4)

The most recent patch here is very short and is a snippet of the code from this patch:

https://savannah.gnu.org/bugs/download.php?file_id=43597

This bug only manifests on KDE systems with Qt 4.4.x that I know of (maybe Qt 5.6.1 through 5.7.0 as well, but not sure).  Qt 5.5.1 seems robust to this bug.  But this is technically an Octave bug.

(in between the household duties)

Tried the patch from comment #13, I don't see the bug anymore.

Should we cc Rik? I think I read he's on KDE a well.

(FYI on my Mageia-6 system Qt is at 5.6.1.)

@Dan:

Just FYI, in mxe-octave Qt is -AFAICS in src/qtbase.mk- at version 5.7.1

Back to KDE, starting from current dev tip as of today, what patches do I have to apply in what order?
1. patch from bug 53276 comment #54? or comment #36?
... then what?

This weekend I have very limited time (real life sneaks in :-) ) but I think I can give it a try.

OK, took a while, but I found the exact change that makes a difference in the patch from Bug #53276.  I added just the following change hunk to the tip:

diff -r ecb5688b875f libgui/src/octave-dock-widget.cc
--- a/libgui/src/octave-dock-widget.cc  Mon Mar 19 14:38:04 2018 -0700
+++ b/libgui/src/octave-dock-widget.cc  Wed Mar 21 19:13:42 2018 -0500
@@ -203,9 +203,13 @@
     if (dock)
       {
         settings->setValue ("MainWindow/windowState", m_parent->saveState ());
+        // Stay window, otherwise will bounce back to window by default because
+        // there is no layout information for this widget in the saved settings.
+        setParent (m_parent, Qt::Window);
         m_parent->addDockWidget (Qt::TopDockWidgetArea, this);
         // recover old window states, hide and re-show new added widget
         m_parent->restoreState (settings->value ("MainWindow/windowState").toByteArray ());
+        setFloating (false);
         focus ();
         QApplication::setActiveWindow (this);
         m_title_widget->setToolTip ("");

As I noted previously, this process has to be fairly precise. 

I should note that the system this is failing on uses KDE/Plasma with what looks like a fairly old version of Qt, 4.4.8.7.  In fact, it looks kind of like a Qt bug to me.

The change above is not a hunk of code executed right before the crash.  Instead it is executed right after startup and then not again until the user does the drag-and-drop.  However, it is setting up the state of the QDockWidget in an incorrect way.  (Still, Qt shouldn't crash--produce a strange result sure--but crash at the point it comes time to convert to tabified?)  When a QDockWidget is dragged, it immediately becomes a floating window (hence the tricky aspect of Bug #53276).  So, it's state is floating but I suspect the internal float variable is out of sync because of the way make_window() is done.

That's why the first thing I did in approaching the changes of Bug #53276 was to get rid of m_floating.  That was a second state variable, only opening confusion with the internal isFloating() state variable.  I'd rather just rely on the one variable as the true state and fix any bugs around that.

Anyway, how to fix this?  My preference might be to just go forward with the patch from #53276 (or something really close).  Or if you think you want to do this small change here first, that's fine.  This bug is in Octave 4.2 release, but hopefully is only happening with Qt 4.4.8.  I believe there is another bug which could be Qt (old) and that is the lack of animated docks:

https://savannah.gnu.org/bugs/?53409

I've experimented on KDE a bit; didn't resolve much, but maybe I have a little clearer picture.

I find that this isn't limited to Documentation widget.  It seems that any combination of windows being tabbified will cause the blue shade and crash.

I also noticed that the Variable Editor doesn't allow the sub-panels to be moved, no less tabbified.  But just a few moments ago, I read the Qt documentation a little more closely and see that the following is deprecated:

QDockWidget::AllDockWidgetFeatures

DockWidgetClosable | DockWidgetMovable | DockWidgetFloatable

(Deprecated) The dock widget can be closed, moved, and floated. Since new features might be added in future releases, the look and behavior of dock widgets might change if you use this flag. Please specify individual flags instead.

In the patches for Bug #53276 I've been replacing:

-    setFeatures (QDockWidget::DockWidgetMovable); // not floatable or closeable

with

+
+    setFeatures (QDockWidget::AllDockWidgetFeatures);

I assume that on KDE, QDockWidget::AllDockWidgetFeatures does not include DockWidgetMovable.  OK, so that I can fix easily in the Bug #53276 patch.

Out of curiosity, I changed the following from main-window.cc:

        setDockOptions (QMainWindow::AnimatedDocks
                        | QMainWindow::AllowNestedDocks
                        | QMainWindow::AllowTabbedDocks);

to

        setDockOptions (QMainWindow::AllowNestedDocks
                        | QMainWindow::AllowTabbedDocks);

and get no crash in KDE.

I did put in a bunch of debugging comments to see where things might be crashing.  However, it seems right away, within Qt and not any of the Octave code, the program hangs.  The patch from Bug #53276 does not crash, even with the animated docks.  I suspect it is because of some settings change tied into the above options, or perhaps not restricting to just QDockWidget::DockWidgetMovable but the patch now using the default float and close buttons.

I will investigate more when I have time.

Yes, I know; one of those inexplicable things.  I can see that the two windows are drawing back and forth, and the focus changes along with it, about a half dozen times.  It could be a KDE bug.  I will step back through the patches I created for 53276 and see exactly where this bug (53392) seems to go away.

@comment # 2:
The only thing common thing I found was that it happens only if it is the Documentation pane that is thrown onto another pane as a first move.
Any other pane drop onto another pane and the bug is avoided for the rest of the Octave session.

Go figure ...

BTW on my desktop PC (just resurrected from video driver issues after some kernel upgrade) CPU usage climbs to a mere 30% while octave is preparing for the crash. On my laptop it is also about 30%.

@Torsten:
I have no build of the stable branch, though later this week I might simply "hg upgrade -r stable" and try with that.

I am not able to reproduce this on Ubuntu Unity: I guess that the bug should also occur on the stable branch, since default was recently merged onto stable for 4.4.

Good find Philip.  I rebooted under my KDE/Plasma drive and observe the same crash as you describe.  When the GUI gets stuck in the blue-shade mode, CPU jumps to 80%.  Worth noting is that Documentation is HTML and when that drag-drop onto the terminal window occurs, there is an obvious redraw of about six times.  HTML rendering is very CPU intensive.  However, you said this issue isn't necessarily restricted to this combination.  Is there something else in common?

I also tried to duplicate the crash with yesterday's updated patch for bug 53276:

https://savannah.gnu.org/bugs/?53276#comment54
https://savannah.gnu.org/support/download.php?file_id=43597

and couldn't do so.  What may have changed between the previous patch and yesterday's that might fix this, I can't think of anything except possibly what I've shown in the attached screen shot...but I wouldn't put much significance in that.  It's quite possible that the older patch in bug 53276 had other kinds of crash bugs that conflated with this one.

Steps to reproduce (fairly reliable):

1. Open a GUI

2. Inside the GUI, drag the Documentation pane into a separate position (not tabbed with any other pane) to the right of the Terminal pane (in any other position the bug seems less reliable)

3. Move the Documentation pane back to the left onto the Terminal pane to get it into tabbed position
(The Documentation pane can also be moved onto Workspace or File browser pane.)

=> result: the pane on which the Doc pane was moved remains blue for a long time, Octave is unresponsive, Octave's main menu Minimize button doesn't work (Octave minimizes momentarily but flashes back to previous size), after a while Octave disappears from sight = crash.

When running "./run-octave --force-gui" the terminal from which is was run mentions:
Segmentation fault - core dumped. but I don't see a core dump

Mageia 6 64bit, KDE/Plasma