bugGNU Octave - Bugs: bug #52556, Octave stops writing to console


bug #52556: Octave stops writing to console

Submitted by:  Georg Wiora <gwiora>
Submitted on:  Thu 30 Nov 2017 08:58:19 AM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  gwiora Open/Closed:  Open
Release:  4.2.1 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)

Wed 25 Apr 2018 12:02:15 PM UTC, comment #7:

With the current version 4.2.2 if still can produce this error. Recently I found a method to "heal" the behavior by entering:

After these commands the console output is available again.

Georg Wiora <gwiora>
Mon 15 Jan 2018 09:33:11 AM UTC, comment #6:

Thank you for your testing hints! I tried the following

1. Can you try making a new m-file by copying say "sym.m" to "mwe.m" and repeating your test?

  • The bug still occurs at the same position, octave of course complains "warning: function name 'sym' does not agree with function filename"

2. You can also try removing the "@seealso" line and see what happens.
*This does not change the behaviour.

3. Can we delete most stuff from mwe.m to find the smallest possible example that shows this bug?

  • Removing all UTF-8 characters: No change
  • *The following did change the behaviour:* Changing document encoding declaration in line 21 from


After this change the error does not occur any more, but help does print a lot of error messages of the following kind:

4. Does the "no-newline-after-help" happen with e.g., "help qr" as well?

  • No, it does not show up with "help qr".
Georg Wiora <gwiora>
Mon 15 Jan 2018 05:53:24 AM UTC, comment #5:

I wonder if this shows up with symbolic because it uses lots of unicode chars / UTF-8 in its docs...

1. Can you try making a new m-file by copying say "sym.m" to "mwe.m" and repeating your test?

2. You can also try removing the "@seealso" line and see what happens.

3. Can we delete most stuff from mwe.m to find the smallest possible example that shows this bug?

4. Does the "no-newline-after-help" happen with e.g., "help qr" as well?

(In my limited experience on Windows, a lot of unicode stuff is broken---various open issues about this. I can't remember if "help sym" is one of them.)

Colin Macdonald <cbm>
Thu 07 Dec 2017 10:48:01 AM UTC, comment #4:

Oops. Sorry for the syntax error. In my test I did not have this. I used a string in single quotes like

I entered/copied all commands to the GUI console. I have not tried them in the script.
When I switched on the diary. All commands and all output lines show up in the diary file.

This is what I see in the diary file (I left out the parts shown by [...]:

I found that the console output stops directly after the string "@sym/asssumeAlso" as shown in my previous post. In the diary file output continues with a dot "." and more text lines produced by the help command.

The help function and the source of the sym command help should be the right places to identify the root of the bug.

Georg Wiora <gwiora>
Thu 07 Dec 2017 01:45:31 AM UTC, comment #3:

There is an error in your third line of code. This may be related to the problem. The apostrophe in "doesn't" ends the text string that you begin with a single quote so that Octave is seeing

which is an error. Try using double quotes so the sequence of commands is now:

Second question, how are you executing these commands? Are you copying and pasting them into the Command Window or are they in an m-file?

If I put the commands into a file cmds.m and run that it works correctly. I do appear to have a problem when pasting in to the GUI. In that case, the last command is not recognized. I can tell that by using "history 10" to look at the last commands and only "help sym" is in the buffer.

Rik <rik5>
Project Administrator
Wed 06 Dec 2017 08:15:21 AM UTC, comment #2:

Thank you for your recommendations. I tried __run_test_suite__ without having the effect of lost output. But I finally found a way to reproduce it. I have to enter the following commands after starting octave:

The console output ends with the following lines:

The first printf does print to console while the second doesn't. I still don't think this bug is specific to symbolic 2.6.0 package, but does occur in other situations too. I frequently ran into it before starting to use symbolic.

Maybe it is usefull to know, that "help sym" does not print a carriage return after last line of help text. The input prompt is placed directly after the last help output. This may be the place where the output breaks.

For completeness I tried the same with geometry-3.0.0 package: Here I could not reproduce the effect.

Georg Wiora <gwiora>
Tue 05 Dec 2017 06:57:21 PM UTC, comment #1:

If I just open Octave and issue an freport I get:

The difference between my report and yours are the two fids python-in and python-out. Presumably these are pipes used for communication with python that were created by the symbolic package. It may be that python or the symbolic package is messing around with stdout and stderr and where they are connected (they should be connected to the console at all times).

What happens if you don't load the symbolic package, or other external code, and use Octave? For example, try running the built-in test suite to stress the interpreter with

After running the test suite, can you execute commands correctly and have the output show up in the console window?

It is also possible that the console code for Microsoft Windows isn't very good.

Rik <rik5>
Project Administrator
Thu 30 Nov 2017 08:58:19 AM UTC, original submission:

I have frequently problems getting console output in the octave-GUI console window. I can not give a minimal example to produce this effect. Currently I see this effect when working with the symbolic package but I got this effect in other not well defined situations too.

I tried to analyze what happens: After console output was lost I switched on the diary and called freport. In my case it showed the following state in the diary file only.

For me this points in the direction of the connection between octave core's console output and GUI console. I guess this sometimes breaks.

Georg Wiora <gwiora>


(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 cbm (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by gwiora (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.




    No changes have been made to this item

    Back to the top

    Powered by Savane 3.3