Hello I am doing simulation, where output is printed on screen. Earlier I was using cerr to print on screen, but later switched to std::cout. The same output is also printed in a log file. But the problem is: after sometime, the output stops printing on the screen; although, the output keeps on printing in the log file. I know that "\n" is required to flush the stream, but even if I use it, there is no output after some time. When exactly output stops is not fixed and changes in different simulations.

Can someone help?
Sparsh

Several tests, just to determine the cause of the stoppage.
1. Clear the upper bit of output to prevent graphic and special codes that are functions to the terminal emulation.
2. Block ESC sequences to the terminal. These can trigger terminal functions.
3. Test for special codes like CTRL-S, which pauses the terminal display.
4. Disable all output stmts except one, then test. Then do the same with each output line.
Determine if stoppage problem is associated with any particular output stmt.
5. Put in extra output stmts. It does not matter if they cause screen to look like garbage, they only track the last known print line. Test if the stoppage is earlier, and maybe determine where.
6. Before every output stmt, put in a debugging output to the screen that gives a sequence number (to identify the last print), identifies the particular line, and any state that would help. After every output stmt, put in a simple print to the terminal that tests if the output is still working. When the output stops, the last thing on the screen with the highest sequence number should identify which line is the cause, and the state. Large amount of state can be saved to the log file marked using the same sequence number.

1 members found this post helpful.

Just coverin' the bases here -- have you checked the state of the Scroll Lock key on your keyboard (if it has that key)?

It wasn't clear from your post whether that could be a culprit, but I don't think there is one among us who hasn't been bamboozled by that key at some point.

1 members found this post helpful.

Never heard of that before! My keyboard has that key, but it does not light anything, even if you press it. What can scroll-lock do?

Generally, when output is too much, it gets stuck. Moreover, since it is random phenomenon, so test 4 & 5 is ruled out. I think it is one of 1,2,3. Can you explain: upper bit of output? Block ESC sequence? special codes? Thanks for your time and reply.

Just a precision: \n doesn't flush the output, it's just a character like the others. What you need in order to flush is to pass in std::endl, or to call flush() explicitly on the stream.
What std::endl does is nothing more than passing "\n" to the stream and calling flush() right after.

From http://publib.boulder.ibm.com/infoce...y/id00067.htm:
Avoid using endl where the new-line character is required but buffer flushing is not, because endl has a much higher overhead than using the new-line character.

Also, I'm not sure if this applies to c++, but I recall having had a problem with ruby when I was sending a text too long to the output function. The solution then was to pass through a function that called puts() with fixed size parts of the input text. I'm not sure what ruby does internally (probably it's not even using cout), but it could be worth checking.

2 members found this post helpful.

Those 1 to 5 tests are suggested specifically because it is random and you do not yet know which output statement is triggering the stoppage. The CTRL-S code printed does the same thing as pressing the SCROLL-LOCK on the keyboard, it pauses the output display.

Clear the upper bit.
You do not need to modify text strings, but binary output is suspect.
If you output any char codes directly, just as a test clear the high bit on them.
<< ch ; ---> << (ch & 0x7F) ;

ESC sequence.
They start with an escape char.
If you have code that outputs characters, then test for the escape.
<< f(x) ----> chfx = f(x); if( chfx == 27 ) { << "ESC" ; } else { << chfx ; }

Special codes.
Outputting char outside the ASCII printing glyph range 32..127, may hit a special code.
These codes are interpreted by VT100,VT102 terminals as functions like clear_screen, switch to alternate font, and others. Most displays emulate the VT100, VT102 functions in software and will respond to these codes. Make sure you do not output these by accident. They will
not do anything special in a log file, but they should be visible.

Likely, somewhere you are outputing raw binary, that by accident is triggering a terminal function, like SCROLL-LOCK. These should show up in the log as "^S" or similar characters, or if you display the log using a font with those characters present, they could look like any strange character.

1 members found this post helpful.

@selfprogrammed
Thanks. I will try these and let you know.