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:  dev 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 11 Dec 2018 07:53:58 AM UTC, comment #14:

@Comment #12: I am using Windows 7.

Georg Wiora <gwiora>
Mon 10 Dec 2018 06:25:57 PM UTC, comment #13:

(Philip here)
I vaguely remember something about garbled characters in the console but those memories need a bit refreshing.

Maybe related, but I do regularly see that there's no more output to the GUI terminal after what looks like some buffer overflow that seems to wipe code for displaying text in the terminal.
E.g., read a big text file with:

more off;
fid = fopen (<some filename of a fairly big file>);
txt = fread (fid, Inf, "*char")
## note absent semicolon at end of last line

... and then very often there's no more output shown at all.

more on

then and trying typing commands indicates that the pager line is displayed but with background color (i.e., invisible).
I couldn't yet establish a robust test case so I didn't report it yet, but it could be relevant here (just guessing).

Philip Nienhuis <philipnienhuis>
Project Member
Mon 10 Dec 2018 05:07:19 PM UTC, comment #12:

@Georg: Your test works correctly for me in Octave 4.4.1. I see:

Also subsequent calls of fprintf still work.

But for 4.3.0+, the console output of "help sym" contains odd characters if the mfile_encoding is set to SYSTEM. This is a regression.
I'll open a new bug report for that.

Which version of Windows are you using? If I remember correctly, we (Philip?) saw that the Windows console prior to Windows 10 was buggy when it comes to UTF-8 (even worse in Windows XP).

Markus Mützel <mmuetzel>
Project Member
Mon 10 Dec 2018 08:44:01 AM UTC, comment #11:

All my files seem to be UTF-8 encoded. Octave gui editor is showing this encoding and octave gui preferences are also set to UTF-8. I even tried to change the file to using UTF-8 with BOM. and added the @documentencoding tag to the header:

But Octave still stops printing after end of help text and does not print the last letter "e" and the last line break.

Georg Wiora <gwiora>
Sat 08 Dec 2018 12:16:26 PM UTC, comment #10:

The "äöü" example works for me with the SYSTEM encoding when I test with a recent version from the default branch. I am still un-sure whether it will work for everyone cause I have some local modifications to relevant packages in MXE Octave.

However, "help sym" displays a lot of scrambled characters. That is because that file is encoded in UTF-8 but we assume it to be encoded in the SYSTEM encoding. Converting it from SYSTEM (CP1252 in my case) to UTF-8 creates these odd characters.

That conversion is done in input.cc in function "file_reader::get_input".
Can we differentiate between .m files from the core or packages (which probably always are UTF-8) on the one hand and user created .m files (which could have any encoding) on the other hand at that point? Does the lexer keep track of this?

Markus Mützel <mmuetzel>
Project Member
Fri 07 Dec 2018 03:03:08 PM UTC, comment #9:

This works correctly for me in 4.4.1 if I use UTF-8 as the .m file encoding.

However, if I set the .m file encoding to SYSTEM (the default on Windows, "CP1252" on my German Windows 10), I can reproduce this bug.

There have been some changes how Octave handles the encoding in .m files in the development branch of Octave which will eventually be released as Octave 5.0.
I will try to test whether this particular use case has been fixed already.

In the meantime, you could manually select to use UTF-8 as the encoding of your .m files. But if you want to use your .m files both in Octave and in Matlab, keep in mind that Matlab uses the SYSTEM codepage on Windows.

Markus Mützel <mmuetzel>
Project Member
Fri 07 Dec 2018 11:05:41 AM UTC, comment #8:

I can not reproduce the workaround with "more on" and "more off". But I see that the out stops only if there are UTF8 characters in the documentation section of a function.

While the following command

does not stop octave from writing to console, the same string in a function documentation block does:

Using "help" command on a function with such a string on console, stops console output for all further commands.

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




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-10 rik5 Carbon-CopyRemoved 72865 => -
    2018-12-08 mmuetzel Release4.4.1 => dev
    2018-12-07 mmuetzel Release4.2.1 => 4.4.1

    Back to the top

    Powered by Savane 3.3