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!

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

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.

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)

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.

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.

Octave builds with "BLAS_LIBS = -lblas"

No more crashes with "export OMP_NUM_THREADS=1"

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?

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)

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

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.

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

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

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?

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.

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.

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

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.

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.

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.

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

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

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.

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

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