Visual Studio C++ 2010 file output halts when buffer full

Topics -- That's Visual Studio C++ but it is not  .NET.

Two programs that I have written recently die deep in Microsoft code when sent either a single character(as in fputc( ' ', fpOut ); or a string as in fprintf( fpOut, "abcd\n" ) ;

I have written over the years at least 500 programs that use the same methods. This fault is new.

The include files and all references to fpOut within a function are included in the attached file. The problem occurs when fpOut->_ptr points near or at the end of the 4096 byte buffer and fpOut->_cnt approaches or reaches zero. Other fpOut-> values are _flag = 10, _file = 4, _charbuf = 0, and of course _bufsiz = 4096.

I attempted an fflush as the end of the buffer was approached:
if( fpOut->_cnt < 64 ) fflush( fpOut ) ;
That did not work. fpOut.txtThe program disappeared into the depths of Microsoft's code. The program is left hanging. The task manager reports that it is using no cycles during this time. The program has to be terminated by the task manager
Who is Participating?
I remember a similar behavior some years ago in one of my projects. the reason was a dll that was built using a wrong threading model. also a mix of single-threaded and multi-threaded runtime libraries might cause strange things to happen. I would suggest to remove statement by statement from the source until the error was gone. if you link against non-standard libraries, you may consider to comment the calls and try without. if nothing helped you may try to using std::ofstream and std::ofstream::write statements as a substitute. however, that probably could not help if the error was caused by memory corruption. if that is the case you only would get some other strange errors at other places.

it looks to me as if the stream was in fail state. then any further operation could cause the stream to hang.

you may call ferror(fpOut) before fputc or fprintf to find out whether the stream is ready for write or not. if not, the stream is in error state or corrupted perhaps by some buffer overflow or by using a wrong pointer before. you could try to call clearerr to reset the error but that only helps if the stream is not corrupted but only the last operation before has failed for some reason. if that is the case you may check errno after each streaming operation to find out the pulprit.

StMike38Author Commented:

I have followed through on your suggestions. The findings:
[1] Immediately after opening the file, fpOut looks totally as expected.
[2] Testing errno_t err by a call "_get_errno( &err );" results in 2 (ENOENT) no matter where the test is made.
[3] Testing int Ret = ferror( fpOut ); yields 0 when fpOut->_cnt is down to zero. In other words, the stream appears ready to write.
[4] By stepping through Microsoft's fputc and its sub-functions, I found that in _write at a line "r = _write_nolock( fh, buf, cnt );" the logic appeared to hang. It turns out that it did not hang totally. Rather, it emerged after between 29 and 31 seconds. The fh was 3 and the cnt was 4096.

This same 30 second "pause" happens every time a 4k boundary is reached. To produce a 170k file (about 42 of 4k units), 21 minutes are added on to produce a file that would normally take just under half a second. In other words, when this phenomenon kicks in, it multiplies the time required by a factor of over 2500.

Yet this slowdown occurs only with one input file among many thousands. I checked one instances. Like the other inputs, it's an HTML in which all characters are printable ASCII -- no control characters, no high-bit-set characters. There is nothing that sets this input file apart from the others.

Thanks for your suggestions so far. Any thoughts on where to from here?

StMike38Author Commented:
Sounds like it is time to upgrade from Visual Studio 2010.  Thanks.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.