bugGNU Octave - Bugs: bug #50880, octave-gui segfault after...

 
 

bug #50880: octave-gui segfault after completion of welcome wizard initialization

Submitter:  Mike Miller <mtmiller>
Submitted:  Tue 25 Apr 2017 09:17:34 PM UTC
   
 
Category:  GUI Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 02 May 2017 09:51:14 PM UTC, comment #14: 

Verified the fix works for this bug and #50396.  Closing reports.

Rik <rik5>
Group administrator
Tue 02 May 2017 09:26:56 PM UTC, comment #13: 

I pushed this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/b605146ed2ed

Does it fix the problem for you?  The change is to initialize the global variables in the application object instead of the interpreter object.  That way, Voct_etc_dir is available for the GUI resource manager initialization.

There are about 50 global variables like Voct_etc_dir.  Many are given default values by the call to install_defaults.  Eventually, I'd like to move variables like this to be members of the application or interpreter object, whichever is more appropriate for each of them.

John W. Eaton <jwe>
Group administrator
Thu 27 Apr 2017 04:52:48 PM UTC, comment #12: 

Yeah that makes sense.

I managed to bisect this specific error to one of the following two related changes (the first one doesn't compile for me):

https://hg.savannah.gnu.org/hgweb/octave/rev/af48d8be62b3
https://hg.savannah.gnu.org/hgweb/octave/rev/252975fdc444

The second of these changesets moved the call to install_defaults from octave::application::init() octave::interpreter::interpreter(). So it occurs later in the startup sequence now, after the application object has been initialized but before the interpreter is started. Meanwhile the GUI application is setting itself up and accessing some of these global parameters that haven't been initialized yet.

Mike Miller <mtmiller>
Group Member
Thu 27 Apr 2017 03:31:36 PM UTC, comment #11: 

This could be because of a race issue between the GUI thread and the Octave interpreter thread.  The interpreter has not yet initialized Voct_etc_dir before the GUI requests it.

See bug #50396 where a similar situation prevents the documentation from being loaded in the GUI.



Rik <rik5>
Group administrator
Thu 27 Apr 2017 03:25:57 PM UTC, comment #10: 

What I have found so far is, that the resource_manager seems not be able to create the settings file because

default_qt_settings_file (void)

returns "/default-qt-settings", i.e. the variable Voct_etc_dir is empty.

Torsten Lilge <ttl>
Group Member
Thu 27 Apr 2017 03:03:25 PM UTC, comment #9: 

Thanks Rik, I can confirm the crash when the environment variable is not set. I'm going to give bisecting another shot with a modified run-octave script.

Mike Miller <mtmiller>
Group Member
Wed 26 Apr 2017 05:57:40 PM UTC, comment #8: 

It's different from the build tree because the run-octave script establishes a fallback in case the file qt-settings does not exist.  In run-octave,


OCTAVE_DEFAULT_QT_SETTINGS="$builddir/libgui/default-qt-settings"; export OCTAVE_DEFAULT_QT_SETTINGS


If I comment this out, and run from the build tree, then I get a segfault.


Rik <rik5>
Group administrator
Wed 26 Apr 2017 05:45:04 PM UTC, comment #7: 

Why is it different if you run it from build tree or from installed location?


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 26 Apr 2017 05:31:28 PM UTC, comment #6: 

Confirmed for me as well with an installed version of the development branch.  I changed my HOME variable to point to somewhere innocuous and I get the segfault as soon as the welcome wizard finishes.

This might be related to threading.  Currently any code in the GUI which calls error() leads to an unhandled exception which then goes to std::terminate.  There is already a bug report about that.

Rik <rik5>
Group administrator
Wed 26 Apr 2017 04:49:40 PM UTC, comment #5: 

Sure it's possible. I know why bug #50396 occurs only when Octave is installed and not in the build tree, but I don't know why this one would behave that way. Besides I was seeing it in my build directory originally, but after deleting and building again that was not reproducible.

I now only see this when running the installed octave binary, not using run-octave. Adding all of the command-line arguments that run-octave inserts does not change anything.

I can try to bisect but that might take a long time, can't devote time to that for now.

Mike Miller <mtmiller>
Group Member
Wed 26 Apr 2017 09:14:26 AM UTC, comment #4: 

could this be related to https://savannah.gnu.org/bugs/?50396

Both reports are linked to starting the GUI and only occur on the installed version.

A.R. Burgers <arb>
Wed 26 Apr 2017 01:37:46 AM UTC, comment #3: 

Same. I started bisecting but that makes it a lot more tedious.

Mike Miller <mtmiller>
Group Member
Tue 25 Apr 2017 11:44:42 PM UTC, comment #2: 

I cannot reproduce the error if I run ./run-octave from
the build tree, but I can reproduce it if I install it proper
(to /usr/local ) and run then...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 25 Apr 2017 10:13:11 PM UTC, comment #1: 

I just run 1fadf480a63b
and it was fine.
Cannot reproduce the problem (Fedora 25 Qt 5.7.1)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 25 Apr 2017 09:17:34 PM UTC, original submission:  

Octave's GUI crashes immediately after completion of the welcome wizard dialog. This is 100% reproducible for me on the default branch. The released 4.2.1 and the stable branch do not have this problem.

To reproduce this you will need to move or delete the ~/.config/octave directory, run Octave as a different user, or with a different temporary HOME directory.

Creating an empty file ~/.config/octave/qt-settings is enough to bypass the welcome wizard and avoid this error. I have built Octave with both Qt 4 and 5 and both exhibit the same behavior.

Stack trace:


Thread 12 (Thread 0x7ff311675700 (LWP 24561)):
#0  0x00007ff34867f54d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ff33fa579f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ff33fa57b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ff34779604f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ff34773f9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ff34756d0f3 in QThread::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ff31d5c56d5 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007ff347571da8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ff348945424 in start_thread (arg=0x7ff311675700) at pthread_create.c:333
#9  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 11 (Thread 0x7ff312ef1700 (LWP 24560)):
#0  0x00007ff34867f54d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ff33fa579f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ff33fa57d82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ff314fbb656 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007ff33fa7f3d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ff348945424 in start_thread (arg=0x7ff312ef1700) at pthread_create.c:333
#6  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 10 (Thread 0x7ff3136f2700 (LWP 24559)):
#0  0x00007ff34867f54d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ff33fa579f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ff33fa57b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ff33fa57b51 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ff33fa7f3d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ff348945424 in start_thread (arg=0x7ff3136f2700) at pthread_create.c:333
#6  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 9 (Thread 0x7ff31cc94700 (LWP 24558)):
#0  0x00007ff34867f54d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ff33e160150 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007ff33e161ee9 in xcb_wait_for_event () from /lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007ff31f32db69 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007ff347571da8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ff348945424 in start_thread (arg=0x7ff31cc94700) at pthread_create.c:333
#6  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 8 (Thread 0x7ff330645700 (LWP 24557)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff330645700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 7 (Thread 0x7ff330e46700 (LWP 24556)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff330e46700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 6 (Thread 0x7ff331647700 (LWP 24555)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff331647700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 5 (Thread 0x7ff331e48700 (LWP 24554)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff331e48700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 4 (Thread 0x7ff332649700 (LWP 24553)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff332649700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 3 (Thread 0x7ff332e4a700 (LWP 24552)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff332e4a700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 2 (Thread 0x7ff33364b700 (LWP 24551)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff339eebc5b in ?? () from /lib/libopenblas.so.0
#2  0x00007ff348945424 in start_thread (arg=0x7ff33364b700) at pthread_create.c:333
#3  0x00007ff3486889bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7ff333664940 (LWP 24550)):
#0  0x00007ff3476ae4e2 in QSettings::setValue(QString const&, QVariant const&) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x00007ff34be3d8eb in shortcut_manager::do_init_data (this=0x55e9218b6a20) at ../libgui/src/shortcut-manager.cc:102
#2  0x00007ff34be0a411 in shortcut_manager::init_data () at ../libgui/src/shortcut-manager.h:78
#3  octave::gui_application::execute (this=0x7ffda3b71ef0) at ../libgui/src/octave-gui.cc:220
#4  0x000055e920e15203 in main (argc=2, argv=0x7ffda3b72178) at ../src/main-gui.cc:104


I don't mind debugging if someone more familiar with GUI startup can help point me in the right direction.

Mike Miller <mtmiller>
Group Member

 

(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 jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by arb (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-02 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-05-02 jwe StatusConfirmed Ready For Test
    2017-04-26 mtmiller StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code