bugGNU Octave - Bugs: bug #59628, Segmentation fault on GUI close

 
 

bug #59628: Segmentation fault on GUI close

Submitter:  Markus Mützel <mmuetzel>
Submitted:  Sun 06 Dec 2020 04:52:28 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 Dec 2020 09:49:56 PM UTC, comment #27: 

@Lars: I agree that my patch broke the way you are using Octave. If you really need the GUI, when executing scripts from the command line, you have to add the '--persist' option. However, in this case, octave won't exit in case of an error.

For fixing this bug while preserving the current behavior when launched from the command line, we have to prevent the interpreter from executing commands or scripts from the command line until the GUI is completely set up (as far as I understand what is going on when this segfault occurs).

Torsten Lilge <ttl>
Group Member
Fri 18 Dec 2020 04:41:40 PM UTC, comment #26: 

I don't think in practice there is much concern.  Programmers who are working on the command-line and using a one-off invocation of octave to do some work, '--eval', are likely to be sophisticated enough to understand options and can use the man page to discover "--persist".

Rik <rik5>
Group administrator
Fri 18 Dec 2020 01:41:08 PM UTC, comment #25: 

Actually, I use the combination --gui --eval without --persist intentionally.

I start scripts automatically in the background that will generate graphics and text output (shown in the command window) and finally wait() till I close the figure or the gui. In case of an error, octave exits and the calling shell script handles the case.

Now I dont see the command window any more because --gui is ignored and if, as suggested, --gui would imply --persist, an error won't antomatically exit and the gui hang around forever.

Of course the desired behaviour could be achieved by modifying the workflow, but the current logic of --gui and --persist has reasonable use cases. So I opt for keeping the old behaviour.

Lars Kindermann <larskindermann>
Fri 18 Dec 2020 11:47:31 AM UTC, comment #24: 

Now if someone uses both --gui and --eval, the GUI doesn't start and there is no warning/error?

Maybe we should at least warn about that usage since some users might not know about --persist and might expect the gui to start if they asked for it?

John W. Eaton <jwe>
Group administrator
Fri 18 Dec 2020 06:17:52 AM UTC, comment #23: 

The following post was accidentally added into a wrong bug report by me:

I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/0fc400f15e35 which prevents that the gui is launched when "--eval CODE" or a FILE is given as command line argument unless "--persist" is given, too.

However, the argument check in main.cc analyzes all given arguments regardless there position in the command string. Arguments behind a possible FILE argument are obviously ignored by octave but are used to set several flags in main.in.cc. This does not only affect the test for launching the gui or not but also the already existing tests.

Torsten Lilge <ttl>
Group Member
Fri 18 Dec 2020 04:46:39 AM UTC, comment #22: 

Torsten's recent cset (3a15c18c705f) fixes this issue for me.  Closing report.

Rik <rik5>
Group administrator
Sun 13 Dec 2020 01:30:51 AM UTC, comment #21: 

It looks like src/main.in.cc is the file to modify.

Rik <rik5>
Group administrator
Sun 13 Dec 2020 01:29:20 AM UTC, comment #20: 

I like Torsten's proposed solution.  If the user just wants to evaluate a command or run a script, there is no reason to start the GUI.  It should be faster, and no segfault.

Rik <rik5>
Group administrator
Sat 12 Dec 2020 06:29:56 PM UTC, comment #19: 

It looks like pending signals cause this segfault if the slot's object is already gone ("exit") when the signal is finally processed.

This brings me to the question if there are really case where it is required to start the GUI without --persist option when a script or commands have to be evaluated. If not, we could just ignore the --gui option in these cases or force --persist if --gui is requested.

Torsten Lilge <ttl>
Group Member
Fri 11 Dec 2020 09:56:26 PM UTC, comment #18: 

I have grafted cset http://hg.savannah.gnu.org/hgweb/octave/rev/be61ce9c3126 to the stable branch.

The remaining issue with segfaulting while executing


octave --gui --eval '1+1,exit'


can reliably reproduced when the editor is visible and editor files are opened through enabling restoring the previous session. A backtrace shows that the segfault is caused by a signal connection in an interpreter thread in line 2022:


connect (this, SIGNAL (update_breakpoints_signal (const octave_value_list&)),
         this, SLOT (update_breakpoints_handler (const octave_value_list&)),
         Qt::QueuedConnection);




Torsten Lilge <ttl>
Group Member
Mon 07 Dec 2020 10:14:50 PM UTC, comment #17: 

The buildbots obviously do not start the gui. Do the other crashes occur when "--gui" is omitted?

Torsten Lilge <ttl>
Group Member
Mon 07 Dec 2020 09:54:27 PM UTC, comment #16: 

I have noticed that fedora buildbots again sporadically crash during doc building. i wonder if this is related.

E.g.:

http://buildbot.octave.org:8010/#/builders/25/builds/1980/steps/6/logs/stdio

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 07 Dec 2020 09:35:04 PM UTC, comment #15: 

The segfault I saw (on the development branch) had the same root cause as reported in the OP. I checked with GDB and compared the backtrace with the OP. Now, the problem seems to be fixed also for me.

I cannot speak for the other topic as reported in comment #6 and comment #5. I was never able to reproduce this on the default branch (i haven't checked on stable).

Hg200 <hg200>
Mon 07 Dec 2020 07:06:42 PM UTC, comment #14: 

The OP seems to be fixed for me with Torsten's change.

Markus Mützel <mmuetzel>
Group administrator
Mon 07 Dec 2020 06:59:37 PM UTC, comment #13: 

I still get a signal 11 exit when executing


octave --gui --eval '1+1,exit'


This is with Qt 5.9.5 (in reference to a previous question).

Rik <rik5>
Group administrator
Mon 07 Dec 2020 06:59:33 PM UTC, comment #12: 

@torsten: 7.0.0 (hg id: be61ce9c3126) still crashes with

octave --gui --eval "1+1,exit"


@jwe: qt is version 5.15.1 on debian testing, xfce.

Lars Kindermann <larskindermann>
Mon 07 Dec 2020 06:34:08 PM UTC, comment #11: 

I have pushed the cset on default. If it generally solves the issue I will graft it into stable.

Torsten Lilge <ttl>
Group Member
Mon 07 Dec 2020 06:31:21 PM UTC, comment #10: 

Mh, wait, the editor is related since a new empty tab is always created whenever the editor is visible. I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/be61ce9c3126 which fixes the bug for me.

Torsten Lilge <ttl>
Group Member
Mon 07 Dec 2020 05:28:41 PM UTC, comment #9: 

The latest observations seem to be unrelated to the OP, where the destructor of file_editor_tab seems the cause of the segfault (and I have already found the "manual" deletion of a child object). Calling octave for evaluation of "1+1" should not trigger the editor.

Finally, I can only confirm the --eval "1+1" case. When starting a recent build from the default branch with a file name, no segfaults occurs.

Torsten Lilge <ttl>
Group Member
Mon 07 Dec 2020 05:26:51 PM UTC, comment #8: 

If it's a threading issue, we may also need to see the output of "thread apply all where", not just "where".

John W. Eaton <jwe>
Group administrator
Mon 07 Dec 2020 05:25:02 PM UTC, comment #7: 

I'm unable to duplicate the crash.

What version of Qt are you using?  I have 5.15.1 on a Debian testing system.

Can you get a stack trace after the crash?  Since this is executing without the command line showing up, maybe the best way is to allow your system to generate a core file ("ulimit -c unlimited" in bash), execute the command that causes the crash, then run gdb on the resulting core file + the octave-gui executable file?

John W. Eaton <jwe>
Group administrator
Mon 07 Dec 2020 05:13:30 PM UTC, comment #6: 

Also confirmed that putting the commands in to file, tst_sig11.m, and then executing


octave --gui tst_sig11.m


also produces a signal11 exit.  So it isn't specific to the "--eval" option.

Rik <rik5>
Group administrator
Mon 07 Dec 2020 05:04:43 PM UTC, comment #5: 

Confirmed that the one-line command


octave --gui --eval "1+1,exit"


exits with signal 11.  This is for Octave 6.1.0 built from tarball on generic Kubuntu 18.04 system.

Rik <rik5>
Group administrator
Mon 07 Dec 2020 10:48:59 AM UTC, comment #4: 

maybe this helps in locating the bug, it can be triggered by command line parameters only:

while

$ for i in {1..10}; do octave --gui --eval "1+1"; done
$

is always ok, but forcing exit from within octave

$ for i in {1..10}; do octave --gui --eval "1+1,exit"; done
octave exited with signal 11
octave exited with signal 11
octave exited with signal 11
octave exited with signal 11
octave exited with signal 11
octave exited with signal 11
octave exited with signal 11
octave exited with signal 11
$

often crashes on my system, both in todays stable and dev but not in 5.2

Another observation: Even when the signal 11 message is emitted, the return code of the octave command is still zero. So main seems to exit fine, and the problem is in a thread?

Lars Kindermann <larskindermann>
Sun 06 Dec 2020 07:57:40 PM UTC, comment #3: 

@Markus: Does this happen each time you are closing the gui
and on the stable branch, too? What is the hg-id? I can not reproduce the crash on my system, but I am several csets behind and currently building from the default branch.

Torsten Lilge <ttl>
Group Member
Sun 06 Dec 2020 07:18:39 PM UTC, comment #2: 

Thanks for the report and info.

If possible, it would be good to fix this issue for the 6.2 release.

For the development branch, I'm working on a significant change to the way the GUI works, including replacing the terminal widget as we have been discussing for quite some time.  It should soon be possible to start Octave as a command line app, open the GUI, close it and return to the command line.  With the changes I'm working on, I think exiting the GUI and command line app is much improved.  I will open a thread on discourse about this today.

Separately, we still have some issues to work out with the way the graphics code accesses graphics objects and their properties.  I'm not sure that has ever been done properly.

John W. Eaton <jwe>
Group administrator
Sun 06 Dec 2020 06:29:07 PM UTC, comment #1: 

I also get random segfaults after closing the gui both in 6.1.1 and 7.0.0 but not in 5.2, on Debian testing. It never happens when I just open and close the gui, but the probability seems to increase whith the complexity of produced graphics. Running the same script from the commandline over and over will sometimes exit ok and sometimes with signal 11.

Finally I found a way to reliably trigger a segfault, but I'm not sure if this is really caused by the same bug:

create a script file, e.g. sig11.m

edit sig11.m
exit


and start it with

$ octave-7.0.0 --gui --persist sig11.m
octave exited with signal 11



Lars Kindermann <larskindermann>
Sun 06 Dec 2020 04:52:28 PM UTC, original submission:  

When closing the GUI with a build from the current default branch, a segmentation fault occurs.
Here the backtrace with hg id e3e887d5f631 on Ubuntu 20.10:

Thread 1 "octave-gui" received signal SIGSEGV, Segmentation fault.
0x00007ffff454dcb2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
(gdb) bt
#0  0x00007ffff454dcb2 in  () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1  0x00007ffff4531880 in QWidget::clearFocus() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x00007ffff4532948 in QWidget::~QWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#3  0x00007ffff7d9ceed in octave::file_editor_tab::~file_editor_tab() (this=0x5555569dea30, __in_chrg=<optimized out>)
    at ../libgui/src/m-editor/file-editor-tab.cc:275
#4  0x00007ffff7da9fcf in octave::file_editor::handle_tab_ready_to_close() (this=0x555555ee2520) at ../libgui/src/m-editor/file-editor.cc:521
#5  0x00007ffff3a74320 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff7d9c647 in octave::file_editor_tab::check_file_modified(bool) (this=0x5555569dea30, remove=remove@entry=false)
    at ../libgui/src/m-editor/file-editor-tab.cc:1777
#7  0x00007ffff7da9c0f in octave::file_editor::check_closing() (this=0x555555ee2520) at ../libgui/src/m-editor/file-editor.cc:441
#8  0x00007ffff7dbe3e7 in octave::main_window::closeEvent(QCloseEvent*) (this=0x5555558a2400, e=0x7fffffffb2b0)
    at ../libgui/src/main-window.cc:2023
#9  0x00007ffff453730e in QWidget::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x00007ffff44f6013 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x00007ffff7dd3f5b in octave::octave_qapplication::notify(QObject*, QEvent*)
    (this=0x55555564b7c0, receiver=<optimized out>, ev=<optimized out>) at ../libgui/src/octave-qobject.cc:132
#12 0x00007ffff3a3e1ca in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007ffff4532685 in QWidgetPrivate::close_helper(QWidgetPrivate::CloseMode) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x00007ffff4552ed6 in  () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007ffff44f6013 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007ffff7dd3f5b in octave::octave_qapplication::notify(QObject*, QEvent*)
    (this=0x55555564b7c0, receiver=<optimized out>, ev=<optimized out>) at ../libgui/src/octave-qobject.cc:132
#17 0x00007ffff3a3e1ca in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff3e0c1ed in QGuiApplicationPrivate::processCloseEvent(QWindowSystemInterfacePrivate::CloseEvent*) ()
    at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#19 0x00007ffff3de52bb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#20 0x00007fffecece35e in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#21 0x00007ffff10e14db in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff10e1788 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff10e1853 in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007ffff3a95843 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
--Type <RET> for more, q to quit, c to continue without paging--c
#25 0x00007ffff3a3ca4b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x00007ffff3a44fc6 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x00007ffff7ddd0f2 in octave::qt_application::execute() (this=0x7fffffffb990) at ../libgui/src/qt-application.cc:68
#28 0x0000555555556531 in main(int, char**) (argc=9, argv=0x7fffffffbcc8) at ../src/main-gui.cc:106


I've also seen the GUI crash on exit on Windows. But I'm not sure if this is the same error.

CC'ing Torsten because he is the GUI expert.

Markus Mützel <mmuetzel>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by hg200 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by larskindermann (Posted a comment)
  • -email is unavailable- added by mmuetzel (Submitted the item)
  • -email is unavailable- added by mmuetzel
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-18 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-12-07 ttl StatusConfirmed Ready For Test
    2020-12-07 rik5 StatusNone Confirmed
    2020-12-06 mmuetzel Carbon-Copy- Added ttl

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code