Cerr causes program to hang

[mykat]

I'm trying to run this on linux, and for some strange reason, one of the statements in the following code snippet does not execute to completion:

 
if (doneComparisons % 10 == 0 && verbose)
{
                              
     cerr << "\r" << (int)(doneComparisons / totalComparisons * 100) << "% of event pairs checked";
     cerr.flush();
                             
}

when (int)(doneComparisons / totalComparisons * 100) evaluates to 54, the code never reaches the cerr.flush() statement. The statement does evaluate if cerr is replaced with cout.

What could be causing this problem?

[Paul McKenzie]

I'm trying to run this on linux, and for some strange reason, one of the statements in the following code snippet does not execute to completion:

I see no program that is runnable. I see some code plucked out of a larger program, where we have no idea what state the program is in when that code is executed, have no idea what type of variables "doneComparisons" or "totalComparisons" are, what values they have, etc.

Post a complete but small program that duplicates what you are seeing, not a snippet. Otherwise there could be any number of reasons why you see no output, one being that verbose does not evaluate to 1.

Regards,

Paul McKenzie

[mykat]

The program is large, and I cannot seem to reproduce the error without running the full program.

Perhaps I can rephrase the question - is there any condition which could cause a running program to hang, as if stuck on an infinite loop, when outputting to cerr?

I don't see any exceptions or any error messages, and any statements after the cerr statement don't execute.

[Paul McKenzie]

The program is large, and I cannot seem to reproduce the error without running the full program.

So maybe the problem is that the "large program" is doing something invalid?

The issue is that you just cannot take a section of code and assume that is where the error originates. In C++, errors can occur after the offending code has been executed, maybe many functions ago. What you're showing us is where everything finally breaks down, and not where the error originates.

Perhaps I can rephrase the question - is there any condition which could cause a running program to hang, as if stuck on an infinite loop, when outputting to cerr?

You're using C++. If you make any type of buffer overrun error, wild/invalid pointer access, etc. or have uninitialized variables, or any other condition that leads to undefined behaviour, then anything can happen anywhere in a program. For all we know, you could be overrunning an array, clobbering the values of other variables with nonsense values, thus causing all sorts of havoc to occur either immediately or later on during the running of the program. No one knows unless we have the full program and run it ourselves.

I don't see any exceptions or any error messages

There is no guarantee that exceptions or "error messages" appear in a buggy C++ program. C++ isn't like Java, C# or whatever other language you may have been using in the past -- you make a mistake in C++, then all bets are off as to what may happen (including having the program seemingly "work").

Regards,

Paul McKenzie

[OReubens]

A car drives down a hill
suddenly the breaks stop working
the car continues driving down the hil because it has no means to stop
at the end of the downwards hil it continues to roll through momentum
finally it crashes into a tree

conclusion: the tree has a bug.


If you didn't get what Paul was trying to describe, this is an analogy that might make sense to you. You detected the car crashing into the tree, but not the real problem. Don't blame the tree.

[mykat]

"No, there is nothing immediately obvious" would have been a perfectly fine answer.

[Paul McKenzie]

"No, there is nothing immediately obvious" would have been a perfectly fine answer.

That answer gives the impression that there is something wrong with cerr, and to move on, blame cerr and use cout instead.

That would be totally false -- the problem isn't with cerr, and just replacing it with cout is not a fix. The explanations given to you explain why cout (as you used) is not a fix even if the program works.

Regards,

Paul McKenzie

[superbonzo]

"No, there is nothing immediately obvious" would have been a perfectly fine answer.

ok, <<supposing>> your program code is correct in all of its parts ( and that your STL implementation is bug-free ), then a reason causing such a std::cerr behavior could be that something else ( eg. a library/framework/... you're using ) replaced the cerr's default stream buffer object with a buggy one, and/or that you're writing a multithreaded app with a std::cerr ( implementation or stream buffer ) causing a deadlock due to improper synchronization ...

[mykat]

That answer gives the impression that there is something wrong with cerr, and to move on, blame cerr and use cout instead.

That would be totally false -- the problem isn't with cerr, and just replacing it with cout is not a fix. The explanations given to you explain why cout (as you used) is not a fix even if the program works.

Regards,

Paul McKenzie

I did not use cout as a workaround - if I had, I wouldn't have started this thread. I merely used it to demonstrate that the cast seems valid, and that the program is actually reaching the cerr statement.

In the interest of tracking down the bug, which thus far I have traced to this cerr statement, I was simply asking if there was any particular condition that anyone here has seen before that could cause ostream to hang. I will confess that I have never had a program behave in this manner from within built in functions. In my experience built in code is generally robust, and will fail relatively gracefully, either terminating the program with an exception, or simply entering a fail state and moving on.

It is a really simple question: have you ever had a program hang, not freeze, on during an output to ostream? If so, what turned out to be the problem?

[mykat]

ok, <<supposing>> your program code is correct in all of its parts ( and that your STL implementation is bug-free ), then a reason causing such a std::cerr behavior could be that something else ( eg. a library/framework/... you're using ) replaced the cerr's default stream buffer object with a buggy one, and/or that you're writing a multithreaded app with a std::cerr ( implementation or stream buffer ) causing a deadlock due to improper synchronization ...

Thank you. That's the kind of constructive response that I'm looking for. I'm not using multithreading. As far as I know, I'm not using anything that should be replacing cerr's buffer object - just the STL and a little bit of Boost.

[Paul McKenzie]

I merely used it to demonstrate that the cast seems valid, and that the program is actually reaching the cerr statement.

Everything (if those variables contain valid values) is valid. That's the point -- the error is not in cerr or any of those statements.

In the interest of tracking down the bug, which thus far I have traced to this cerr statement,

Again, cerr is not the error. That is where the program finally breaks down. The error occurred before those statements were executed.

I will confess that I have never had a program behave in this manner from within built in functions. In my experience built in code is generally robust, and will fail relatively gracefully, either terminating the program with an exception, or simply entering a fail state and moving on.

Nothing guarantees any function or object to work in C++ if the program has already corrupted memory in any way. The cerr is a global variable. It isn't protected from harm by any part of your program. If you have a buffer overrun, you could be corrupting the memory that cerr relies on to work correctly.

It is a really simple question: have you ever had a program hang, not freeze, on during an output to ostream? If so, what turned out to be the problem?

If you make any mistake in a C++ program, anything can happen, and I mean anything. Today that bug is causing one problem, tomorrow, cerr "works", but soemthing else is getting messed up. That is the nature of a C++ program that has memory allocation errors, buffer overruns, or any errors similar to those.

Regards,

Paul McKenzie

[2kaud]

the code never reaches the cerr.flush() statement

How do you know - and how do you know it's not the flush that's causing the problem? Have you used the debugger to trace through the if block? What happens if you put a cout statement immediately after the cerr one and remove the flush?

Has cerr been tied to another output stream? Are you using c++11?

[mykat]

How do you know - and how do you know it's not the flush that's causing the problem? Have you used the debugger to trace through the if block? What happens if you put a cout statement immediately after the cerr one and remove the flush?

That's how I traced the problem. Any cout statement immediately after the cerr statement is not output.

Has cerr been tied to another output stream? Are you using c++11?

I am using a slightly older GNU compiler which is not quite up to date, but does use some c++11 features. Unfortunately I have no control over the compiler version. I have not explicitly tied the cerr output stream, and the handful of functions that I'm using from Boost should not be doing so.

I'm looking into valgrind right now to perform some memory debugging.

[2kaud]

Do you have any other cerr statements that get executed before this one? What happens if you put a cerr << "cerr here"; statement immediately prior to the cerr causing the problem?

[Paul McKenzie]

I'm looking into valgrind right now to perform some memory debugging.

ok.

Going back to this:

when (int)(doneComparisons / totalComparisons * 100) evaluates to 54, the code never reaches the cerr.flush() statement

Is this code being performed in some sort of a loop? If so, maybe the issue is not that the result is 54, but that the loop was executed "n" times. If the value of "n" is always the same when the error occurs, then maybe something that starts at the n-th iteration could be causing the issue.

Regards,

Paul McKenzie