bugGNU Octave - Bugs: bug #40689, MinGW: octave-3.7.7+.exe process...


bug #40689: MinGW: octave-3.7.7+.exe process keeps running after GUI starts

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Sun 24 Nov 2013 11:36:56 AM UTC
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Thu 23 Jan 2014 05:17:56 PM UTC, comment #16: 

That (invoking octave-gui.exe directly and placing it in /bin rather than libexec) is exactly what John D. patched in the MXE builds.
Works well.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 23 Jan 2014 05:00:12 PM UTC, comment #15: 

Is there any resolution here?  It seems like we can/want to run octave-gui.exe directly on Windows platforms instead of the wrapper.

Rik <rik5>
Group administrator
Sun 24 Nov 2013 10:42:50 PM UTC, comment #14: 

There are solutions, or workarounds if you like, that do work well.

I don't see a problem in using --force-gui flags on Linux, or calling octave-gui.exe on Windows. It just has to be outlined somewhere in a word or two.

So in any case we have the first tip/hint for Linux packagers :-)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 09:44:34 PM UTC, comment #13: 

Sorry, you are right about requiring --force-gui.  I remember this problem now, and Mike is correct that it is because we want Octave to still be able to execute scripts from stdin.  I must have misinterpreted one of my tests.

In any case, I don't see that we can fix this problem without redesigning how we want Octave to start.

John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 09:38:26 PM UTC, comment #12: 

On Linux I get the same thing as Philip. I think it is because if Octave is not reading from a terminal, it assumes a script on stdin. Then because there is no stdin when running from a launcher, it sees EOF and exits.

I cannot run from a launcher or from Alt-F2 (run program in gnome-shell) without --force-gui. Both octave and octave-gui launch nothing visible to me.

Mike Miller <mtmiller>
Group administrator
Sun 24 Nov 2013 09:31:46 PM UTC, comment #11: 

I just checked again, but from the KDE menu and using a launcher I only get Octave-GUI to run using "..../octave --force-gui"

My system is Mageia-2

Using the launcher to start octave-cli does need a terminal.
In the output of "ps ax" I see
28274 ?      Rl  kdeinit4: konsole [kdeinit] --workdir ~ --caption=GNU
28277 pts/1  Ssl+/usr/local/bin/octave-cli

Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 09:16:22 PM UTC, comment #10: 

It should work to start "octave" without the --force-gui option. 
That works for me from a launcher.  You don't see two processes in that case because the launcher is executing the octave process without a controlling terminal so the wrapper program can exec instead of having to fork, give up the controlling terminal, and then exec.

Using a launcher to run octave-gui directly (not in a terminal) should work.  Running octave-gui with a terminal will not work properly because you'll have a controlling terminal and less won't work properly (it will be looking to the controlling terminal for keyboard input).

However, running octave-gui directly from a launcher is not working properly for me.  I'll see if I can figure out why.

John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 08:37:01 PM UTC, comment #9: 

Of course I'll help. But mostly for MinGW as I have experience on mainly that platform as regards Octave.

As to the MinGW binary (through mxe-octave) I suppose there's little hints and tips needed on this specific subject; adapting the shortcuts in the makeinst-script.sh is about all that is needed (I suppose the majority wants an ".exe" installer rather than a zip file).

On Linux I simply don't see the extra octave invocation, not even with "ps ax".
FYI, I start Octave through the KDE Menu, or a desktop launcher, invoking:
"/usr/local/bin/octave --force-gui".
Any other command line option (/usr/local/bin/octave; /usr/local/bin/octave-gui) doesn't work; unless I select "run in terminal".

Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 07:48:45 PM UTC, comment #8: 

It seems to me we need some way to fully emulate execv.  Then the new process (octave-gui or octave-cli) would completely replace the original octave process and we wouldn't have the two programs running.

Or, we could just redesign the way we invoke Octave on Windows (or maybe all systems).  It's complicated by having to deal with the controlling terminal problem on Unixy systems and wanting Octave to not completely detach itself from the terminal if it is started from a command line shell.  I think this is something we could look at again after the release, especially if users seem confused by the existence of octave-cli, octave-gui, and octave with the --no-gui and --no-gui-libs options.

My guess is they will be confused and we will be looking at this again.

And yes, we should have some tips in the NEWS file, or in a separate file that gives hints for packagers.  Would you like to help write those tips?

John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 07:39:03 PM UTC, comment #7: 

What you say is essentially this:

The octave-3.7.7+ (& shortcut octave) executables are only required for batch file processing.
It is only when starting the gui through octave that this issue arises.

I do think that packagers should be (made) aware of this.

Would you mind if I set status to "postponed" & severity "minor"?
My reasoning:
I think it is preferrable to not have unneeded windows and processes around the place. But as there is a workaround the priority is probably low.
If you don't agree I'll close this bug (or you can do it as well)

Thanks for the explanation

Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 05:33:30 PM UTC, comment #6: 

I don't think the changeset would have any impact on startup time of the GUI.

If you agree with the necessity of the changeset and the possible workaround in Windows (it's easy enough to associate a shortcut with octave-gui.exe instead of octave.exe), please close this bug report.

Michael Goffioul <goffioul>
Sun 24 Nov 2013 05:20:18 PM UTC, comment #5: 

Ok that is different from what I'm seeing on Linux, I'll open another bug about that.

Mike Miller <mtmiller>
Group administrator
Sun 24 Nov 2013 05:19:04 PM UTC, comment #4: 

Sorry, I now understand the cs in question makes sure Octave can be called in a batch script.
Makes sense as for e.g., create the html for OF packages I always had to do it in Octave itself; calling it from MinGW as outlined in the OF developers section didn't work for me.

On a perhaps related note, since a few days my mxe cross-builds take considerably longer to show the GUI. Is there a connection with that changeset?

Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 05:14:45 PM UTC, comment #3: 

Do I understand correctly that the cs is required only for being able to run ./run-octave from a build dir?

Starting octave-gui(.exe) of octave-gui-3.7.7+(.exe) indeed avoids the extra cmd32.exe window.

Starting octave.exe with the --force-gui option only shows the taskbar button for the cmd32.exe window for a while, but the GUI never starts.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 04:57:03 PM UTC, comment #2: 

I think this is a result of this changeset:


The problem this changeset is solving is to keep the octave "wrapper" process active while the child process (CLI of GUI) is running. And this is exactly what you're seeing. The wrapper process is the one executing in the cmd32.exe window.

I believe this changeset is still required. Without it, the wrapper will exit as soon as the child process starts (the child process running in a "detached" mode). This makes it impossible to use run-octave with the expected bevahior. Or calling "octave" in a shell/batch script: something like "octave -q --eval 'my_long_function()'" will exit before my_long_function is actually executed.

I think a simple workaround to avoid having the pending cmd32.exe window is to call octave-gui directly, instead of using the octave wrapper executable.

Michael Goffioul <goffioul>
Sun 24 Nov 2013 04:52:42 PM UTC, comment #1: 

I actually see similar behavior with a Linux build today. If I start the GUI from a terminal (octave, octave --force-gui, or octave-gui) the command never returns to the shell even after the GUI exits. Ctrl-C does not kill this process, I have to use Ctrl-\ (sends a QUIT signal) to get it to exit.

Mike Miller <mtmiller>
Group administrator
Sun 24 Nov 2013 11:36:56 AM UTC, original submission:  

(Probably a mere cosmetic flaw)

When starting Octave GUI, I now see two Octave windows/processes in the taskbar:
1. A (minimized) cmd32.exe window (the process is called octave-3.7.7+.exe in Task Manager)
2. Octave GUI (octave-gui.exe in TM).

Manually closing windows 1. doesn't affect 2; nor does repeatedly typing Ctrl-C in (a restored) window 1.
Closing Octave ends both windows as it should.
So no problems AFAICS (unless needlessly occupying 1324 KB RAM is a problem).

IIRC until a few days ago (but could be earlier) I always saw window 1 after starting Octave, but that disappeared as soon as the GUI appeared.

(build details: MXE-cross build (cs 17989:4465699450c2 configure.ac: Don't use internal macro variable ax_blas_f77_func_ok) made Nov. 23)

Philip Nienhuis <philipnienhuis>
Group Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


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 mtmiller (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 project members can vote.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-04 rik5 Dependencies- bugs #41699 is dependent
    2014-01-23 rik5 StatusPostponed Fixed
        Open/ClosedOpen Closed
    2014-01-19 mtmiller CategoryNone GUI
    2013-11-24 philipnienhuis Severity3 - Normal 2 - Minor
        StatusNone Postponed

    Back to the top

    Powered by Savane 3.12