bugGNU Octave - Bugs: bug #53392, [GUI] Octave crashes when moving...


bug #53392: [GUI] Octave crashes when moving Documentation pane within GUI onto another pane

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Tue 20 Mar 2018 08:06:49 PM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  philipnienhuis Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 02 Apr 2018 05:51:13 PM UTC, comment #33:

For reference, the patch went on to stable here: http://hg.savannah.gnu.org/hgweb/octave/rev/36f17567ffa1.

Rik <rik5>
Project Administrator
Mon 02 Apr 2018 05:47:03 PM UTC, comment #32:

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.

Rik <rik5>
Project Administrator
Sun 01 Apr 2018 11:06:43 PM UTC, comment #31:

OK, that makes sense now.  This (Bug #53392) and Bug #53409 are ostensibly tied back to the same Qt bug.  I think the changeset here is still a more complete way of reparenting to the QMainWindow, so I'd prefer to just keep this as a separate changeset.  It's up to you.

Dan Sebald <sebald>
Sun 01 Apr 2018 10:46:02 PM UTC, comment #30:

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

Torsten Lilge <ttl>
Project Member
Sun 01 Apr 2018 10:43:52 PM UTC, comment #29:

@Torsten: What versions of Qt are you using on Unity and KDE?  It could be very likely that this crash bug is only associated with that range of versions (5.6.1 <= V < 5.7.1) that have the non-relocatable QDockWidgets.  Recall, that bug is one in which the sub-panels snap back to their original location when attempting to move.

Dan Sebald <sebald>
Sun 01 Apr 2018 09:26:01 PM UTC, comment #28:

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

Torsten Lilge <ttl>
Project Member
Fri 30 Mar 2018 11:20:51 AM UTC, comment #27:

It helped fix or circumvent the crash on my Linux systems(KDE/Plasma), and it has no negative consequences on Windows. Good!
There never were issues on Windows like the one described in the original bug report anyway.

So I'm in favor of just applying the patch in comment #13, so that this issue is out of the way in a separate bug fix.
From there on other bugs can be fixed separately, like you suggest.

just my .02 $c

Philip Nienhuis <philipnienhuis>
Project Member
Thu 29 Mar 2018 07:53:10 PM UTC, comment #26:

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.

Dan Sebald <sebald>
Sun 25 Mar 2018 09:02:34 PM UTC, comment #25:

Dan, I know all of that; there's just a miscommunication between me and Torsten that seems to have started with comment #14.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 25 Mar 2018 05:50:33 PM UTC, comment #24:

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.

Dan Sebald <sebald>
Sat 24 Mar 2018 10:57:27 PM UTC, comment #23:

Torsten: sure, I see what you mean, but the background of that stanza in my comment #14 is that I actually never build or use stable branches, so your comment #20 was a bit lost on me.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 24 Mar 2018 10:47:10 PM UTC, comment #22:

@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

Torsten Lilge <ttl>
Project Member
Sat 24 Mar 2018 04:08:39 PM UTC, comment #21:

AFAIU this bug was from before the split to 4.4.0.
Dev or stable wouldn't matter much, I saw little Qt patches applied to dev that aren't applied to stable.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 24 Mar 2018 06:13:11 AM UTC, comment #20:


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

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

Torsten Lilge <ttl>
Project Member
Fri 23 Mar 2018 11:09:09 PM UTC, comment #19:

That's good news Philip.  Yes, we should get the others in the loop.  I'll let them know that you have Qt 5.6.1 (I thought you had an older 4.x version).  Qt 5.6.1 is supposedly where this bug


came in.

Dan Sebald <sebald>
Fri 23 Mar 2018 09:31:04 PM UTC, comment #18:

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


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.

Dan Sebald <sebald>
Fri 23 Mar 2018 09:18:15 PM UTC, comment #17:

Which patch(es) should be applied here?

John W. Eaton <jwe>
Project Administrator
Fri 23 Mar 2018 07:21:32 PM UTC, comment #16:

(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.)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 23 Mar 2018 04:44:34 PM UTC, comment #15:

For now, let's just confirm the attached patch fixes the bug here.  We'll deal with Bug #53276 after, as I think we need to clear some of these things to make testing easier for KDE users (Rik should be able to do some testing as well if we get Bug #53409 fixed).  So, revert back to the tip, apply the patch here, and test please.  If that fixes this bug, great.  Thanks.

Dan Sebald <sebald>
Fri 23 Mar 2018 04:23:41 PM UTC, comment #14:


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.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 23 Mar 2018 04:00:34 PM UTC, comment #13:

I've created a changeset out of the diff hunk below.  If you want to apply this first, prior to other changes (it would be covered by the patch for Bug #53276; if the patch here is applied, then I'll have to freshen the one at Bug #53276) to make clear where this bug was, that's fine.  There is a bug in Qt 5.6.1 through 5.7.0 that has complicated issues as far as testing for people on KDE (which seems to use 5.6.1 on its most recent version), so I may end up freshening the changeset at Bug #53276 anyway.

(file #43650)

Dan Sebald <sebald>
Thu 22 Mar 2018 12:29:34 AM UTC, comment #12:

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,  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:


Dan Sebald <sebald>
Wed 21 Mar 2018 06:03:13 PM UTC, comment #11:

I've checked out the version prior to adding the multi-pane variable editor:

changeset:   24812:ed9ba20d6ed3
user:        Daniel J Sebald <email@address>
date:        Mon Feb 19 20:13:15 2018 -0600
summary:     Make the variable editor multi-panel via a QMainWindow layout (bug #53046)

changeset:   24811:a8df0552cc42
user:        John W. Eaton <email@address>
date:        Thu Mar 01 11:18:44 2018 -0500
summary:     * lu.cc: Note possible issues with ipvt vector.

and I'm still seeing this blue shade hang/crash on KDE.  I'm not sure I want to go searching back to some indefinite time for whether this ever worked properly or if perhaps it is related to the Qt version, might be a Qt bug, might be a Plasma bug, etc.

Here is all I know that seems of significance:

1) The hang/crash seems to happen immediately, but the animated QDockWidget does appear to draw correctly.  That is, the animation takes place, then it is as though that very last draw before transitioning to a tabified layout fails.

2) If I remove the AnimatedDock option, there is no hang/crash, but (and this may be important) it's also the case that the QDockWidgets cannot be moved, even though they have Movable feature set.  They should be movable.  This could be a Qt bug.

3) The changeset in Bug #53276 seems to fix this.  Why, I'm not sure, but that seems the best lead in trying to figure this out.

Dan Sebald <sebald>
Wed 21 Mar 2018 09:18:59 AM UTC, comment #10:

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:


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


+    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);


        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.

Dan Sebald <sebald>
Wed 21 Mar 2018 06:51:11 AM UTC, comment #9:

Exactly, could very well be an upstream bug.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 20 Mar 2018 11:31:40 PM UTC, comment #8:

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.

Dan Sebald <sebald>
Tue 20 Mar 2018 10:48:14 PM UTC, comment #7:

It isn't very reassuring that your patch fixes the crash for unknown reasons. There's no guarantee that this bug won't resurface anytime some other change to the GUI is pushed.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 20 Mar 2018 10:30:08 PM UTC, comment #6:

@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%.

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

Philip Nienhuis <philipnienhuis>
Project Member
Tue 20 Mar 2018 09:34:20 PM UTC, comment #5:

Ubuntu Unity... Neither can I reproduce this bug for Mint Cinnamon.

Dan Sebald <sebald>
Tue 20 Mar 2018 09:29:06 PM UTC, comment #4:

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.

Torsten Lilge <ttl>
Project Member
Tue 20 Mar 2018 09:28:10 PM UTC, comment #3:

Oh, I should point out the reason I can't think of much that I changed between patches would affect this is because the drag/drop steps described use the underlying Qt mechanism rather than pressing the float button of the custom title bar.

Dan Sebald <sebald>
Tue 20 Mar 2018 09:23:38 PM UTC, comment #2:

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:


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.

Dan Sebald <sebald>
Tue 20 Mar 2018 08:16:04 PM UTC, comment #1:

Another observation:

AFAICS, this only happens when moving the Documentation pane onto some other pane as a first action of moving panes around within the main GUI window.
After first moving e.g. the Terminal pane onto some other pane (does not crash), I cannot reproduce the crash anymore.
Maybe some uninitialized variable in the Documentation pane code?

Philip Nienhuis <philipnienhuis>
Project Member
Tue 20 Mar 2018 08:06:49 PM UTC, original submission:

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

Philip Nienhuis <philipnienhuis>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by siko1056
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-02 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2018-03-23 sebald Attached File- => Added octave-drag_drop_gui_main_window-djs2018mar23.patch, #43650
    2018-03-21 siko1056 Carbon-Copy- => Added siko1056
    2018-03-20 philipnienhuis StatusNone => Confirmed
    2018-03-20 sebald Attached File- => Added float_as_toplevel-djs2018marXX-difference_between_patches_Screenshot_from_2018-03-20_16-18-12.png, #43607

    Back to the top

    Powered by Savane 3.4