bugGNU Octave - Bugs: bug #49609, Ctrl+C crashes Octave and the...

 
 

bug #49609: Ctrl+C crashes Octave and the Desktop

Submitter:  José Luis García Pallero <jgpallero>
Submitted:  Tue 15 Nov 2016 09:10:31 AM 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:  * 4.2.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 21 Feb 2017 02:53:39 PM UTC, comment #50: 

I had the same problem (instant logout / crash of the desktop when pressing Ctrl-C in Octave, if started from the desktop) in Xubuntu 16.04 with the XFCE4 desktop.

The proposed patch fixed the issue.
Thanks!

Roland Baudin <roland65>
Sat 18 Feb 2017 03:35:16 PM UTC, comment #49: 

I have compiled the "default" branch (hg id dfee8aa390c2), and run it via a Desktop link on Unity Gnome. And (compared to the behavior before, see for example my commment #23) it is all fine now. Thanks for fixing this!

Hartmut <hardy>
Sat 18 Feb 2017 03:08:26 PM UTC, comment #48: 


> Could you please try this and verify that it also fixes the problem for you?


I have tried it and seems to have fixed the issue for me. I built both c897282f1ec8 and d222db279c21 (the one right before your fix) from source, and installed them in separate directories. Running d222db279c21 I could reproduce the problem, with c897282f1ec8 it was fixed.

Carnë Draug <carandraug>
Group Member
Sat 18 Feb 2017 12:37:55 PM UTC, comment #47: 

OK, that fixed it for me, too in current dev!

It fixed the immediate crash of the desktop, to be precise. Still having the "problem" of Octave crashing after holding down Ctrl-C for a while. So that seems to be another - much less severe - bug.

Lars Kindermann <larskindermann>
Sat 18 Feb 2017 01:29:01 AM UTC, comment #46: 

I was finally able to reproduce the problem.  The following changeset (on stable and merged with default) appears to fix it for me.

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

Could you please try this and verify that it also fixes the problem for you?

Thanks.

John W. Eaton <jwe>
Group administrator
Fri 17 Feb 2017 03:12:06 AM UTC, comment #45: 

I had a session with jwe on IRC where he tried to find more details about this bug. Seems that the problem is that Octave sends signals to its whole process group.  When starting Octave from the launcher, Octave will be in the same process group has the session manager and so Octave.

jwe on IRC:

> OK.  One difference is that when you do it with Octave, gnome-session is getting the interrupt signal (= 2) directly instead of getting a terminate signal (= 15).  But the real question is why would sending SIGINT to Octave generate an interrupt to the session? I'm guessing it is this code, and the session is in the same process group?  http://hg.savannah.gnu.org/hgweb/octave/file/0c9195baea1a/libgui/src/thread-manager.cc#l69 


Looking at list of processes, I see the following for the Octave started from the Gnome launcher (I added the "--norc" to the desktop file to make sure the configuration was not the cause of it):


 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
[...]
 4131  4140  4140  4140 ?           -1 Ssl   1000   0:00      \_ x-session-manager
[...]
 4140  4279  4140  4140 ?           -1 Sl    1000   2:47          \_ /usr/bin/gnome-shell
[...]
 4279 18136  4140  4140 ?           -1 Sl    1000   0:01              \_ /usr/local/libexec/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui --norc --force-gui


While starting octave from the command line and the same options:


 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
[...]
18335 18336 18336 18336 ?           -1 Ssl   1000   0:00          \_ /usr/local/libexec/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui --norc --force-gui


Why setting OMP_NUM_THREADS=1 solves the issue on my system I don't understand.

Carnë Draug <carandraug>
Group Member
Thu 16 Feb 2017 03:47:38 PM UTC, comment #44: 

I can replicate this issue on Gnome 100% without any code. Simply start Octave, no code whatsoever, just press "C-c" and the whole desktop crashes; I'm back at the login manager.  I'm using gnome 3.14.1 on Debian Jessie (current Debian stable).  How I replicate the issue:

1. Octave 4.2.0 was built from source and installed with default prefix of "/usr/local/"
2. Start Octave from the gnome desktop (the desktop file installed by Octave was unmodified)
3. Press "C-c" at the Octave prompt. Crashes the desktop (save any pending work before doing this)

Things that prevent the issue:

  • If I start Octave GUI from the command line, I don't have this issue. Both "/usr/local/bin/octave" and "/usr/local/bin/octave --force-gui", none crashes the desktop.


  • If I edit the desktop file at "/usr/local/share/applications/www.octave.org-octave.desktop" with this line "Exec=env OMP_NUM_THREADS=1 /usr/local/bin/octave --force-gui %f", then it no longer crashes (don't forget to run "sudo update-desktop-database" after modifying the desktop file)


Carnë Draug <carandraug>
Group Member
Tue 07 Feb 2017 08:46:26 PM UTC, comment #43: 

Same here. Windows 7. New ThinkPad P50. Octave crashes when ctrl-c and also sometimes plot().

Jonas Ohr <johr>
Mon 23 Jan 2017 04:28:04 PM UTC, comment #42: 

In addition to the last comment, to add
"export OMP_NUM_THREADS=1"
before using the commands "/usr/bin/octave --force-gui %f" or "/usr/bin/octave --force-gui" in the .desktop file does not solve the problem.

Fellype do Nascimento <fellype>
Mon 23 Jan 2017 04:24:11 PM UTC, comment #41: 

The same happens here! ctrl+c breaks the desktop even without anything (a loop or a calculation) running.
I'm running octave-4.2.0 on Slackware 14.2, with KDE 4.14.

I have made the following tests:

a- On a konsole terminal:
a1-- using the command "/usr/bin/octave --force-gui %f",  octave opens and shows the message: "error: no such file /home/fellype/%f" and closes abruptly
a2-- using the command "/usr/bin/octave --force-gui" command, octave opens fine and does NOT crash with "ctrl+c"
a3-- using the command "/usr/bin/octave" command, octave opens (the gui) fine and also does NOT crash with "ctrl+c"

b- Editing the .desktop launcher:
b1-- using the commands "/usr/bin/octave --force-gui %f" or "/usr/bin/octave --force-gui", "ctrl+c" breaks the desktop
b2-- using the command "/usr/bin/octave" without "Terminal=true", octave does not open the gui, but a "octave-gui" process starts to run
b3-- using on of the commands "/usr/bin/octave","/usr/bin/octave --force-gui %f" or "/usr/bin/octave --force-gui" with "Terminal=true", octave opens fine and does NOT crashes with "ctrl+c"

Its worth to say that when I use b3 to launch octave, I can close the terminal windows and octave still running and shows the message (twice):
">> attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
error: unexpected exception while parsing input"

I hope this information helps you find the source of the problem.
Cheers

Fellype do Nascimento <fellype>
Tue 03 Jan 2017 08:34:28 PM UTC, comment #40: 

Just hit this bug on Arch Linux, KDE, using Arch's octave package. Examining my system log, there's a number of additional process crashes the octave crash (firefox, pulseaudio), I assume due to the loss of the session. That said, the "Could not start ksmserver" message does seem to be running in a GUI context, so the X server is still alive and responsive (cursor exists, can select text in error message, server restarts with Ctrl+Alt+Backspace). System log also has a stack trace (no symbols) if it's any help:

Process 9644 (octave-gui) of user 1000 dumped core.

                                                    Stack trace of thread 9644:
                                                    #0  0x00007ff042c87626 _ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_ (libstdc++.so.6)
                                                    #1  0x00007ff044987109 _ZN20octave_user_functionD1Ev (liboctinterp.so.4)
                                                    #2  0x00007ff044987369 _ZN20octave_user_functionD0Ev (liboctinterp.so.4)
                                                    #3  0x00007ff0444c3aee _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_12octave_valueESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE8_M_eraseEPSt13_Rb_tree_nodeIS9_E (liboctinterp.so.4)
                                                    #4  0x00007ff044f1f219 _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N12symbol_table8fcn_infoEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E (liboctinterp.so.4)
                                                    #5  0x00007ff044f1f0ec _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N12symbol_table8fcn_infoEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E (liboctinterp.so.4)
                                                    #6  0x00007ff044f1f0ec _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N12symbol_table8fcn_infoEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E (liboctinterp.so.4)
                                                    #7  0x00007ff044f1f0ec _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N12symbol_table8fcn_infoEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E (liboctinterp.so.4)
                                                    #8  0x00007ff044f1f0ec _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N12symbol_table8fcn_infoEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E (liboctinterp.so.4)
                                                    #9  0x00007ff044f1f0ec _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N12symbol_table8fcn_infoEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E (liboctinterp.so.4)
                                                    #10 0x00007ff042660cff __cxa_finalize (libc.so.6)
                                                    #11 0x00007ff044492003 n/a (liboctinterp.so.4)



Anonymous
Mon 02 Jan 2017 09:13:00 AM UTC, comment #39: 

I confirm this in Debian testing (stretch) XFCE desktop
with octave, octave-common, liboctave4 from Debian experimental (rc-buggy)

Anonymous
Sun 18 Dec 2016 01:45:08 PM UTC, comment #38: 

I tried different kernels but same behaviour under linux 4.2, 4.4 and 4.8:

100% reproducible crash of the xfce desktop on the very first CTRL-C either with OpenBlas or standard Blas libs linked in when starting Octave (current dev) via a start menu entry pointing to (build-dir)/run-octave

When starting from a terminal shell it takes 100-1000 CTRL-C to kill Octave (dev and 4.0) and I get the message

octave exited with signal 6 (or 11 or 2)

No Problems when forcing single-thread.

Lars Kindermann <larskindermann>
Sat 17 Dec 2016 07:17:18 PM UTC, comment #37: 

jwe - holding down Ctrl+C when a BLAS routine is being called, or when Octave is idle at the prompt? I still can't get a crash by just starting Octave and holding down Ctrl+C for several minutes at the prompt.

But ok, looks like the symptom here is the same as bug #47400, at least for the why Octave is crashing part.

I have no idea why Octave crashing is causing certain desktop environments to crash, and I still can't see how that is Octave's fault.

Mike Miller <mtmiller>
Group Member
Sat 17 Dec 2016 03:45:55 AM UTC, comment #36: 

Octave builds with "BLAS_LIBS = -lblas"

No more crashes with "export OMP_NUM_THREADS=1"

Lars Kindermann <larskindermann>
Fri 16 Dec 2016 02:29:50 PM UTC, comment #35: 

Are you using a multi-threaded BLAS library?

Is this a duplicate of bug #47400?

I can confirm that holding down Ctrl-C causes my Octave to eventually crash and I am currently linking with Open BLAS on a Debian system.  If I do


export OMP_NUM_THREADS=1


prior to starting Octave, I can't seem to get it to crash with Ctrl-C.

John W. Eaton <jwe>
Group administrator
Fri 16 Dec 2016 01:37:39 PM UTC, comment #34: 

sorry, continued once more, there was a bad markup in my text...

But when I untick the "run in terminal" option, the very first CTRL-C kills the whole desktop and leaves me at the login screen. Sometimes, but very rarely, the process

/home/kinder/usr/octave/src/.libs/lt-octave-gui

will survive this.

To me it looks like if the mother process of octave in some cases after a CTRL-C receives the signal 6 (SIGABRT) and gets killed: If octave is started by the Desktop it kills the Desktop, if a terminal sits in between, just that terminal is killed. And when started from command line, the shell seems to correctly handle and report that signal.

Any idea how I can continue to help digging out the rabbit?

Lars Kindermann <larskindermann>
Fri 16 Dec 2016 01:31:49 PM UTC, comment #33: 

continued (message was trunctated)...

But when I untick the "run in terminal" option, the very first CTRL-C kills the whole desktop and leaves me at the login screen. Sometimes, but very rarely, the process

/home/kinder/usr/octave/src/.libs/lt-octave-gui
+verbatim+
will survive this.

To me it looks like if the mother process of octave in some cases after a CTRL-C receives the signal 6 (SIGABRT) and gets killed: If octave is started by the Desktop it kills the Desktop, if a terminal sits in between, just that terminal is killed. And when started from command line, the shell seems to correctly handle and report that signal.

Lars Kindermann <larskindermann>
Fri 16 Dec 2016 01:26:35 PM UTC, comment #32: 

Got the mesage. So for Linux (Xubuntu 16.04) I can reliably reproduce the following behaviour:

Starting Octave 4.0.0 from a terminal and holding down CTRL-C for few seconds:

kinder@PC:~$ octave
octave exited with signal 6
kinder@PC:~$

Starting Octave 4.3.0 (todays dev) from a terminal and holding down CTRL-C for many seconds:

kinder@PC:~$ usr/octave/run-octave
octave exited with signal 2
kinder@PC:~$ ^C
kinder@PC:~$ usr/octave/run-octave
octave exited with signal 6
kinder@PC:~$

More often it dies with signal 6. Apport was never triggered yet, so I cannot provide a stack trace for the current dev. Is there a way to force this?


If I start octave 4.0.0 from a XFCE starter it dies silently after a few CTRL-C

If I create a XFCE starter for 4.3.0 (current dev) with the command "usr/octave/run-octave --force-gui"
and tick the "run in terminal" option it also dies silently after few hundered CTRL-C, together with this terminal, too.

But when I untick the "run in terminal" option, the very first CTRL-C kills the whole desktop and leaves me at the login screen. Sometimes, but very rarely, the process

/home/kinder/usr/octave/src/.libs/lt-octave-gui
+verbatim+
will survive this.

To me it looks like if the mother process of octave in some cases after a CTRL-C receives the signal 6 (SIGABRT) and gets killed: If octave is started by the Desktop it kills the Desktop, if a terminal sits in between, just that terminal is killed. And when started from command line, the shell seems to correctly handle and report that signal.

Any idea how I can continue to help digging out the rabbit?


(file #39250)

Lars Kindermann <larskindermann>
Thu 15 Dec 2016 07:26:55 PM UTC, comment #31: 

There have been Ctrl+C problems on all operating systems that have different underlying causes, much of the interrupt/signal handling code in Octave is highly OS-specific, please don't assume that they all have the same cause.

The stack trace you have provided is partial, and is based on Octave 4.0. Can you reproduce this with the current development branch and provide a full stack trace of all running threads?

Mike Miller <mtmiller>
Group Member
Thu 15 Dec 2016 12:46:01 PM UTC, comment #30: 

This is the error:


octave-gui assert failure: *** longjmp causes uninitialized stack frame ***: /usr/lib/x86_64-linux-gnu/octave/4.0.0/exec/x86_64-pc-linux-gnu/octave-gui terminated


Here is a stack trace, maybe somebody gets a hint which module to look into:


Stacktrace:
 #0  0x00007f4697c11428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
         resultvar = 0
         pid = 3835
         selftid = 3836
 #1  0x00007f4697c1302a in __GI_abort () at abort.c:89
         save_stage = 2
         act = {__sigaction_handler = {sa_handler = 0x2d30303033666431, sa_sigaction = 0x2d30303033666431}, sa_mask = {__val = {3559305383445423671, 3276212736508309556, 3472328296227676272, 3472339291342909488, 2314885530818457632, 2314885530818453536, 2314885530818453536, 7022364554195640352, 7162524643962481507, 3472328318561694051, 7363776144298358573, 3274715270390757219, 3472328296226648109, 3475143045726351408, 2314885530819502128, 2314885530818453536}}, sa_flags = 538976288, sa_restorer = 0x88}
         sigs = {__val = {32, 0 <repeats 15 times>}}
 #2  0x00007f4697c537ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f4697d6a8a2 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
         ap = <error reading variable ap (Attempt to dereference a generic pointer.)>
         fd = 2
         on_2 = <optimized out>
         list = <optimized out>
         nlist = <optimized out>
         cp = <optimized out>
         written = <optimized out>
 #3  0x00007f4697cf456c in __GI___fortify_fail (msg=<optimized out>) at fortify_fail.c:37
         do_abort = 2
 #4  0x00007f4697cf446d in ____longjmp_chk () at ../sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:100
 No locals.
 #5  0x00007f4697cf43c9 in __longjmp_chk (env=0x7f4697bdb020 <current_context>, val=1) at ../setjmp/longjmp.c:38
 No locals.
 #6  0x00007f469706b445 in octave_jump_to_enclosing_context () from /usr/lib/x86_64-linux-gnu/liboctave.so.3
 No symbol table info available.
 #7  0x00007f469903ee54 in ?? () from /usr/lib/x86_64-linux-gnu/liboctinterp.so.3
 No symbol table info available.
 #8  <signal handler called>
 No locals.
 #9  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
 No locals.
 #10 0x00007f468ae19dfb in ?? () from /usr/lib/libopenblas.so.0
 No symbol table info available.
 #11 0x00007f4693fe76ba in start_thread (arg=0x7f4684ddc700) at pthread_create.c:333
         __res = <optimized out>
         pd = 0x7f4684ddc700
         now = <optimized out>
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139940853565184, 4635331733764338529, 0, 140723561241295, 139940853565888, 140723561241424, -4694712218554567839, -4694678960181316767}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
         not_first_call = <optimized out>
         pagesize_m1 = <optimized out>
         sp = <optimized out>
         freesize = <optimized out>
         __PRETTY_FUNCTION__ = "start_thread"
 #12 0x00007f4697ce282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
 No locals.
StacktraceAddressSignature: /usr/lib/x86_64-linux-gnu/octave/4.0.0/exec/x86_64-pc-linux-gnu/octave-gui:6:/lib/x86_64-linux-gnu/libc-2.23.so+35428:/lib/x86_64-linux-gnu/libc-2.23.so+3702a:/lib/x86_64-linux-gnu/libc-2.23.so+777ea:/lib/x86_64-linux-gnu/libc-2.23.so+11856c:/lib/x86_64-linux-gnu/libc-2.23.so+11846d:/lib/x86_64-linux-gnu/libc-2.23.so+1183c9:/usr/lib/x86_64-linux-gnu/liboctave.so.3.0.0+6d7445:/usr/lib/x86_64-linux-gnu/liboctinterp.so.3.0.0+d17e54:/usr/lib/libopenblasp-r0.2.18.so+302dfb:/lib/x86_64-linux-gnu/libpthread-2.23.so+76ba:/lib/x86_64-linux-gnu/libc-2.23.so+10682d
StacktraceTop:
 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
 ?? () from /usr/lib/libopenblas.so.0
 start_thread (arg=0x7f4684ddc700) at pthread_create.c:333
 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109


Lars Kindermann <larskindermann>
Thu 15 Dec 2016 12:16:51 PM UTC, comment #29: 

See also bugs #49702 and #49849

If they relate to the same source, the CTRL-C problem seems to exist both in Windows and different flavours of Linux. And because it is in 4.0.0 already it is not new in the code. But why didn't it occur a long time ago?

Perhaps a race condition induced by the Ctrl-C handler and improved system libs or kernels make it more probable?

Lars Kindermann <larskindermann>
Mon 12 Dec 2016 07:20:22 AM UTC, comment #28: 

Running Xubuntu 16.04 64bit and getting CTRL-C crashes in Octave frequently, both in self-compiled current dev and also the Octave 4.0 from the Ubuntu distribution.

Simply hitting CTRL-C at the command prompt repeatedly will trigger the crash after a while.

When running from the terminal shell I just get
"octave exited with signal 6"
 
When running from the XFCE menu the complete X session crashes.

I cannot reproduce this bahavior on another PC running Lubuntu 32bit.

Lars Kindermann <larskindermann>
Tue 29 Nov 2016 12:47:17 AM UTC, comment #27: 

By the way, I am occasionally unable to break out of a "while true; end" loop in the GUI. The octave-gui process goes to 100% and Ctrl+C does nothing. Still, does not crash my desktop environment.

It's probably better to test with a different example that can be interrupted more reliably like "pause(10)". Or just entering Ctrl+C at the prompt when Octave is idle.

Mike Miller <mtmiller>
Group Member
Tue 29 Nov 2016 12:37:56 AM UTC, comment #26: 

If I had to debug why unity is crashing, I would probably take a look at https://wiki.ubuntu.com/Unity/FilingBugs. This page suggests a few alternative ways to debug why unity is crashing, including crash logs being saved in /var/crash and also how to start unity with gdb from a virtual console.

Doing this might lead to a hint as to why the desktop is crashing/aborting/exiting because of something Octave is doing, and maybe indicate that Octave is doing something wrong, or maybe it's something in Qt or the desktop integration libraries.

This looks like it's rapidly starting to go down a rabbit hole unfortunately, and I'm still unable to reproduce (not having any machines on hand with either Unity or KDE).

Mike Miller <mtmiller>
Group Member
Mon 28 Nov 2016 09:43:26 PM UTC, comment #25: 

Yes, that's right: Ctrl+C interrupts the while loop, forces Unity to restart and leaves (in the case of Ubuntu 16.04) Octave running.

After restarting the Octave GUI process (close the GUI, re-open it via the .desktop link) I can do the same "game" again, I get the same kind-of-crash once again.

This kind-of-crash leaves me a single line of text in ~/.xsession-errors:

upstart: unity7-main-Prozess beendet, wird neu gestartet

This is german, and just means: "upstart: unity7-main process finished, will be restarted".

Hartmut <hardy>
Mon 28 Nov 2016 09:21:49 PM UTC, comment #24: 

So the Ctrl+C does interrupt the while loop? And at the same time it kills or forces Unity to restart, but leaves Octave running? That's impressive.

When you say this occurs only once, are you still testing in the same instance of Octave that was running from the first Unity session? What if you exit Octave normally and start another one from the Unity panel launcher? Does it then repeat the process?

If Octave isn't actually crashing itself, only somehow sending a message or a signal to the parent desktop environment causing it to exit or restart, I don't have an easy answer how to debug that. Maybe look at the desktop session logs and see if there are any suggestive messages (I don't know where those log files would be, maybe ~/.xsession-errors).

Mike Miller <mtmiller>
Group Member
Mon 28 Nov 2016 09:06:39 PM UTC, comment #23: 

On my PC (Ubuntu 16.04 with Unity) the Deskopt session recovers in the following way:

  • start Octave (GUI) via a .desktop link
  • "while true ; end" and Ctrl+C
  • result: "pseude crash"
    • short full screen image (Unity login image I think)
    • afterwards: all other desktop applications are closed (crashed)
    • Octave GUI still running (the same instance, with same pid)
  • once again: "while true ; end" and Ctrl+C
  • result now: "all fine"
    • no login image of the desktop manager at all
    • all other applications continue working properly
    • Ocave GUI also still there (still same pid)


So the "pseude crash" only works once, afterwards everything seems fine.

How do I figure out the exit status? (I can only produce this when starting Octave via a .desktop link, and this "disconnects" the terminal, see comment #6 and comment #8)

Hartmut <hardy>
Mon 28 Nov 2016 08:39:49 PM UTC, comment #22: 

When Unity recovers, is it the same Octave session or a new instance of Octave? What does `getpid` return in Octave before and after?

Has anyone been able to determine in what way is Octave exiting? Is there a specific signal or exit status? And why is this exit condition causing certain desktop environments to exit and/or restart themselves, maybe on certain distributions?

Mike Miller <mtmiller>
Group Member
Mon 28 Nov 2016 08:33:21 PM UTC, comment #21: 

I had observed this bug on my PC with Ubuntu 14.04 and Unity desktop (see comment #3 and later). Now, I have upgraded this very same PC to Ubuntu 16.04 (still with Unity) and re-compiled Octave 4.2.0. As a result, this bug has changed it's behavior: Pressing Ctrl-C during a long Octave loop now shows me a full screen Unity image for a few seconds, but then the deskopt session recovers and afterwards I even get the Octave GUI session back. So no proper crash any more, but still an akward behavior.

Hartmut <hardy>
Tue 22 Nov 2016 02:29:58 PM UTC, comment #20: 

I also hit this bug (4.2.0 installed from packages in Gentoo) on a KDE system (KF5 with still some KDE4 elements present).

Moreover, I saw the same crash (exactly the same behavior) occur when using Cantor, KDE's GUI for math applications. See

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

for details.

Erik Quaeghebeur <equaeghe>
Thu 17 Nov 2016 01:57:45 PM UTC, comment #19: 

@Mike: Thank you for your explanations. So my problems with finding and using this .deskopt file were all due to my installation into prefix=/opt/octave-4.2.0.

Hartmut <hardy>
Thu 17 Nov 2016 01:41:53 AM UTC, comment #18: 

In response to your side notes

  • the .desktop file is installed to ${prefix}/share/applications on 'make install', which is the correct place to install it
  • the Icon directive is also correct, as it uses the short name of the icon, which the desktop environment looks for in a pre-defined icon search path


If you install with prefix=/usr, everything works as expected.

If you install to some other location like /opt (which I also do), then you will need to manually copy ${prefix}/share/applications to ~/.local/share/applications, and ${prefix}/share/icons to ~/.local/share/icons. Or possibly set the XDG_DATA_DIRS environment variable to something like


XDG_DATA_DIRS=/opt/octave/share:/usr/local/share:/usr/share


In short, the desktop and icon files are being built and installed correctly, you just may have to go through extra steps to register these files to the desktop system if you are not installing as root to prefix=/usr.

Mike Miller <mtmiller>
Group Member
Thu 17 Nov 2016 01:33:25 AM UTC, comment #17: 

The "flashback" environment is not the same as the full GNOME (version 3) desktop.

Mike Miller <mtmiller>
Group Member
Wed 16 Nov 2016 10:18:15 PM UTC, comment #16: 

In my Ubuntu 14.04 I can also alternatively start a graphics session that is called

  • GNOME Flashback (Compiz), or
  • GNOME Flashback (Metacity)

I am not quite sure what kind of "Gnome" this starts.

But starting any of those two modes, and using any of the aforementioned .desktop files to start Octave, DOES then also create the crash (of the full Gnome session) on Ctrl-C in Octave for me.

So this problem might not only be correlated to the Windows manager (Gnome,  Unity, KDE).

Hartmut <hardy>
Wed 16 Nov 2016 10:10:05 PM UTC, comment #15: 

I have now also tried using the .desktop file that is built and installed along with Octave 4.2.0. It uses "Exec=/opt/octave-4.2.0/bin/octave --force-gui %f". But then I also DO get the crash.

Side note:

  • The .desktop file that is generated during the installation of Octave is very well hidden in the folder /octave/etc/icons. Would it make sense to move it to somehwere where it can be found more easily? Maybe to /octave or to /octave/bin ?
  • This "official" .desktop file also does NOT properly use the Octave icon (it has a funny "Icon=octave", can this work?). This makes it look very boring when used. Could we change this line to something like "Icon=/opt/octave-4.2.0/etc/icons/octave-logo-256.png"?
Hartmut <hardy>
Wed 16 Nov 2016 10:03:29 PM UTC, comment #14: 

For the record, I use GNOME and Octave itself does not crash itself, and does not crash the GNOME desktop environment, when running from a .desktop file and using Ctrl+C in Octave's command window, whether something is running or not.

So far we have seen that it affects Unity and KDE, not GNOME.

Mike Miller <mtmiller>
Group Member
Wed 16 Nov 2016 09:51:35 PM UTC, comment #13: 

I have tried (on Ubuntu 14.04) a .local file

  • without the "Terminal=true" line
  • using Mike's suggestion: "Exec=/opt/octave-4.2.0/bin/octave --force-gui --silent"


Then I can properly start the Octave GUI with the .desktop file, and I DO get the crash (see comment #3) back! So this crash does not only happen when calling "run-octave", I also see it when directly calling the octave binary.


Hartmut <hardy>
Wed 16 Nov 2016 09:49:26 PM UTC, comment #12: 

In fact you should be using the octave.desktop file that is built and installed along with Octave, which correctly sets the Exec field to what it needs to be.

Mike Miller <mtmiller>
Group Member
Wed 16 Nov 2016 09:41:06 PM UTC, comment #11: 

"Exec=octave --force-gui --silent" is what I have in my .desktop file. Does the crash only occur when the .desktop file is calling run-octave?

Mike Miller <mtmiller>
Group Member
Wed 16 Nov 2016 09:37:58 PM UTC, comment #10: 

Yes, maybe there is a problem with calling "run-octave" directly from the .desktop file. But how else am I suppposed to start the Octave GUI via a launcher? When I use a .desktop file (without the "Terminal=true" line again) that has "Exec=/opt/octave-4.2.0/bin/octave" or "Exec=/opt/octave-4.2.0/bin/octave-4.2.0" than Octave will just NOT start at all.

Hartmut <hardy>
Wed 16 Nov 2016 09:27:05 PM UTC, comment #9: 

Well at least this is a clue. Maybe "run-octave" is only meant to be launched from a terminal, unlike the prefix/bin/octave which does the job of forking and detaching from the launching terminal. Are you all running "run-octave"?

Removing KDE from the summary.


Pantxo Diribarne <pantxo>
Group Member
Wed 16 Nov 2016 09:06:25 PM UTC, comment #8: 

When I add the line "Terminal=true" at the end of my .desktop file (see comment #4), and then start Octave with it, then

  • this crash (see comment #3) disappears!
  • an additional empty bash terminal windows pops up


(This is still on Ubuntu 14.04.)

Hartmut <hardy>
Wed 16 Nov 2016 01:19:18 PM UTC, comment #7: 

Just to say that I am using KDE 4.14.9 on openSUSE 13.2 and I do not get any crash with Ctrl-C when using the GUI.

Guillaume <gyom>
Wed 16 Nov 2016 12:53:51 PM UTC, comment #6: 

So this crash is not KDE specific right? Do all of you use .desktop files for launching Octave? If so, does "Terminal=true" change anything (except the terminal window popping up)?

I could test this my self but don't want to crash my desktop :-)


Pantxo Diribarne <pantxo>
Group Member
Tue 15 Nov 2016 11:01:17 PM UTC, comment #5: 

While I don't get the crash specifically on the while 1 loop, I dare not press CTRL-C in Octave these days. I'm on Ubuntu 14.04.

As I commented in #47400 and as someone also reported in comment 3 in this thread, CTRL-C inside Octave can bring down my entire session. For me this seems related to interrupting OpenBLAS.

If I start Octave and just hold down CTRL-C for 20 seconds or so, then about 50% of the time I get a milder crash. Not the session ending, just Octave blinking out of existence with "octave exited with signal 6". This is in GUI mode.

Ceral Paquet <octavebugs>
Tue 15 Nov 2016 10:24:20 PM UTC, comment #4: 

Some more details on my crash under Ubuntu 14.04:

  • I do NOT get this crash when I start the Octave GUI via "/opt/octave-4.2.0/run-octave" in a bash terminal window.
  • I do NOT get this crash when I start the Octave GUI via "/opt/octave-4.2.0/run-octave --force-gui" in a bash terminal window.
  • I DO get this crash when I start Octave GUI via a "Octave 4.2.0 (opt)" file in my "~/.local/share/applications" folder. This file creates a nice icon in my Unity launcher. Clicking onto this icon starts Octave (like all other applications under Ubuntu with Unity). The content of this .desktop file is


[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Icon[de_DE]=/opt/octave-4.2.0/libgui/src/icons/logo.png
Name[de_DE]=Octave 4.2.0 (opt)
Exec=/opt/octave-4.2.0/run-octave --force-gui
Comment[de_DE]=startet Octave 4.2.0 GUI (selbstkompiliert)
Name=Octave 4.2.0 GUI (opt)
Comment=startet Octave 4.2.0 GUI (selbstkompiliert)
Icon=/opt/octave-4.2.0/libgui/src/icons/logo.png

  • I cannot start the Octave GUI at all via a .desktop file, when I skip the "--force-gui" option in this .desktop file.
Hartmut <hardy>
Tue 15 Nov 2016 10:08:45 PM UTC, comment #3: 

I can reproduce this under Ubuntu 14.04.

When I type "while 1 ; end" in the Octave-GUI terminal, and then stop this silly loop with Ctrl-C, then Octave crashes AND the whole Ubuntu Unity session fully crashes. Wow!

My Octave 4.2.0 is self built (only one single configure option "--disable-docs" to work around the bug with osmesa under Ubuntu 14.04), and I still use qt4.

Hartmut <hardy>
Tue 15 Nov 2016 02:50:31 PM UTC, comment #2: 

It crashes in all cases I type Ctrl+C, whether if try to stop a silly loop as


while 1
;
end


or if I type Ctrl+C in the propmpt >> when Octave is waiting for an instruction

José Luis García Pallero <jgpallero>
Tue 15 Nov 2016 02:17:34 PM UTC, comment #1: 

Could you make a simple test script that shows the problem?
I tried with

a=(randn(1000));
for jj=1:10000
disp(jj)
tic;
inv(a)*a;
toc
endfor

and I can interrupt it with Ctrl-C w/o any problem.
(This is on Fedora 24)

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 15 Nov 2016 09:10:31 AM UTC, original submission:  

I've downloaded Octave 4.2.0 from ftp://ftp.gnu.org/gnu/octave/octave-4.2.0.tar.lz. I've compiled and checked and all runs without errors, but I have a problem with the GUI: when I type Ctrl+C in order to stop a script , Octave crashed and also the entire KDE system. I receive the message


Could not start ksmserver. Check your installation


and the KDE session is closed. This error does not occur using octave-cli.

I'm using Debian Sid with its KDE and QT related packages

José Luis García Pallero <jgpallero>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by roland65 (Posted a comment)
  • -email is unavailable- added by johr (Posted a comment)
  • -email is unavailable- added by fellype (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 equaeghe (Posted a comment)
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by octavebugs (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by jgpallero (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 -
    2017-10-03 mtmiller Dependencies- bugs #52153 is dependent
    2017-02-18 carandraug StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-02-18 jwe StatusNone Ready For Test
    2016-12-16 larskindermann Attached File- Added usr_lib_x86_64-linux-gnu_octave_4.0.0_exec_x86_64-pc-linux-gnu_octave-gui.1000.crash, #39250
    2016-11-16 pantxo SummaryKDE crash when Ctrl+C in Octave GUI Ctrl+C crashes Octave and the Desktop
    2016-11-15 rik5 Carbon-CopyRemoved 72865 -
    2016-11-15 rik5 Release4.2.0-rc4 4.2.0

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code