bugGNU Octave - Bugs: bug #59100, "__debug_octave__"...


bug #59100: "__debug_octave__" doesn't work on Windows

Submitted by:  Markus Mützel <mmuetzel>
Submitted on:  Sat 12 Sep 2020 09:10:06 AM UTC  
Category:  Octave Function Severity:  2 - Minor
Priority:  3 - Low Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  6.0.90 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 15 Sep 2020 02:53:56 PM UTC, comment #7: 

Thanks for taking care of this.

Works for me now as expected.

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Mon 14 Sep 2020 08:42:29 PM UTC, comment #6: 

I changed the Windows command for this function to start with "cmd /c" so a new terminal window will be started.  See changeset http://hg.savannah.gnu.org/hgweb/octave/rev/56b9a468145a.  Marking as "Ready for Test".

Rik <rik5>
Project Administrator
Sun 13 Sep 2020 05:45:05 PM UTC, comment #5: 

So it sounds like the command from comment #2 should be adopted.

The extra bit of text printed in the Octave Command Window, rather than in the new shell, is annoying but not tragic for an internal function that won't get executed very often.

I might make a guess that of the two output streams, STDERR and STDOUT, perhaps system() on Windows is not re-directing STDERR at the same time as STDOUT.

On Linux,

octave:4> [status, output] = system ("ls NO_SUCH_FILE")
ls: cannot access 'NO_SUCH_FILE': No such file or directory
status = 2
output =

You can see that STDOUT has been captured in output (but there was nothing to capture) and that the error message on STDERR went directly to Octave's command window.  Probably something similar is happening with gdb and when it was started it sent version information to STDERR.

Rik <rik5>
Project Administrator
Sun 13 Sep 2020 05:21:36 PM UTC, comment #4: 

With the command string from comment #2, a new window opens with a gdb shell that is attached to the current Octave process.

But still, some output displays at Octave's command window, which I wouldn't expect for an asynchronous system call:

>> __debug_octave__
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

But like Rik already wrote in comment #2, this might be a different bug.

Markus Mützel <mmuetzel>
Project Member
Sun 13 Sep 2020 05:12:06 PM UTC, comment #3: 

I don't have any way to test (I'm Linux only), but if someone can verify John D.'s suggestion we can just change the script to use that command on Windows platforms.

Rik <rik5>
Project Administrator
Sat 12 Sep 2020 11:29:23 PM UTC, comment #2: 

msys2 has a start script file that recalls start as:

cmd //c start "${@//&/^&}"

If I change it in _debug_octave_ to:

command_string = "cmd /c start gdb -p %d";

it seems to work

John Donoghue <lostbard>
Project Member
Sat 12 Sep 2020 08:33:11 PM UTC, comment #1: 

The second output being undefined is a different issue.  You could open a new bug report for that.

As for the first part of this report, the "start" program should launch a new Command Window and shell and then run the specified command.  If it is somehow re-using the existing Command Window where Octave is running then there is probably a problem with how we are using "start".

The documentation for the command is at https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/start.

Can you experiment with some of the options?  Perhaps "/wait" or "/elevate" need to be thrown?  Also in testing, use the command which includes "gdb -p %d" where %d is replaced by the results of getpid().

Rik <rik5>
Project Administrator
Sat 12 Sep 2020 09:10:06 AM UTC, original submission:  

IIUC, running "__debug_octave__" on Windows should open an msys2 shell with a running gdb that is attached to the Octave process.
Instead, gdb seems to execute shortly with some output in Octave's command window:

>> __debug_octave__
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

"gdb" does not seem to run after that.

This is just an internal, undocumented function. And it doesn't look like any harm is done. But it would still be nice if this could work as intended.

If I remove "async" from the "system" function arguments, it seems to work as expected.
Contrary to expectations, "gdb" seems to have started asynchronously (i.e. not blocking Octave).
Also, the second output argument isn't set:

>> [status, output] = system('start gdb', false)
status = 0
error: element number 2 undefined in return list

Maybe an error in the "system" function on Windows?

Markus Mützel <mmuetzel>
Project 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

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-15 mmuetzel StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2020-09-14 rik5 StatusNeed Info => Ready For Test
    2020-09-12 rik5 Priority5 - Normal => 3 - Low
        StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5