fflush on stderrr causes program to crash

Question

I am redirecting stderr to a log file on Windows Phone Runtime:

int stdError = 0;
FILE* pLogFile = NULL;

// Redirect stderror to a logfile
if ( ! m_logFilePath.empty( ) )
{
    // Get a duplicate file descriptor for stderror
    // This returns -1 on failure
    stdError = ::_dup( ::_fileno( stderr ) );

    if ( stdError != -1 )
    {
        // Redirect stderror to a log file so we can capture
        // ffmpeg error information
        // Ignore the return value (nothing we can do if this fails)
        ::freopen_s( &pLogFile, m_logFilePath.c_str( ), "w", stderr );
    }
}

The program intermittently crashes while calling fflush(stderr);. When I don't redirect stderr everything seems to be working fine.

Answer 1

It's windows so who knows?

Try std::cerr.flush(); because I can totally see windows doing their own thing again (like sockets not being like files, they like doing their own IO stuff).

Using what I just said above puts the task to their standard library, rather than assuming it's a file and such. Remember "abstraction", it makes sense flush is a method, it is a verb, and we don't care how (or in this case don't (want) to know) so let's just assume flush does what flush ought to do!

Leave a comment if this doesn't work and I shall have a think.

I don't use windows or windows phones (I am not one of the lucky 24 out there in the world :P) but I do know that there are I/O problems ("differences") on Windows, fortunately MinGW and co hide them from me :)

OR

Change your tactics, if I really wanted to side-step the problem (because it isn't your code) create a new class called my_error_stream or something, that extends std::ostream (that way you can use it like std::cerr which "is a" std::ostream).

Put a static method in that called get_error_stream() or something that returns one of two classes derived from my_error_stream, one forwards right to std::err, the other to a file.

It depends on how you like your code to look and feel, I said this way because it keeps the implementations separate, and under their own "branch" of the class hierarchy.

It doesn't really answer your question, but your code seems fine, and Windows sucks at pipes and sockets.