I'm trying to output a zlib compressed string to stdout and something really strange happens. After running the zlib deflate operation successfully (all the correct return values checked), I try to output the result unformatted with either of these methods:
fwrite((void*)output, 1, numbytes, stdout);
OR
for(int i=0; i != numbytes; ++i)
cout.put(output[c]);
if(!cout.good())
throw error();
In either case nothing is output and stdout is broken. In the case of the iostream code, cout.good() returns true, no failbits are set! When using fwrite I check ferror and thats fine too!!! By stdout being broken, I mean that nothing is output via stdout for the rest of the app session. I tried reseting the stdout error state with the respective interfaces to no avail.
I'm strongly inclined to believe this is a library error, as something like this really shouldn't malfunction silently.
All this is happening under OSX 10.6 running XCode 4.2.
This is probably an XCode or GDB issue. I can't reproduce the error running from console, or under Windows.
Related
I am fairly new to using gdb debugger and so coming across the code being displayed when I ran gdb left me having no use for the debugger. I am unfamiliar with the code being displayed but a did a little research and I assume I accidentally opened up a "thread"? It's hard to explain something I do not understand but I will link a picture explaining what I am talking about. Basically I want to revert back to the "basic" display of my actual code and not this: displayed by the debugger
Your program called one of scanf family of functions, with a NULL stream.
Usually this happens when you don't check for errors. For example:
FILE *fp = fopen("/file/which/does/not/exist", "r");
char ch;
fscanf(fp, "%c", &ch); /* BUG: should check fp!=NULL first. */
You should always check return value from any function that may fail.
You can see which code called into the fscanf with GDB where command.
After last week's updated to Xcode 8.3, in a C/C++ program the output from a printf statement no longer appears on the screen without a newline. Thus I can't prompt for the user to enter a number, and have them type in that number on the same line following the input prompt.
Neither flushing the output buffer [fflush(stdout) or cout << endl] nor setting the output buffer to NULL [setbuf(stdout, NULL)] addresses this problem, but rather is a question specifically about Xcode 8.3 seemingly being broken.
With the scanf commented out, the output of the program below is:
Enter a value for x: Value of x is: 0
With the scanf in place, the output from the first printf never shows up. If you go ahead and type in a value and press enter, only then does it show up. Output is:
3
Enter a value for x: Value of x is: 3
Full test program is here:
#include <iostream>
using namespace std;
int main() {
int x=0;
printf("Enter a value for x: ");
//scanf("%d", &x);
printf("Value of x is: %d\n", x);
return 0;
}
My work-around has been to revert back to Xcode 8.2.1, downloaded from developer.apple.com/xcode/downloads/
8.3.2 was announced last night and addresses this supposedly:
It is standard behavior in C for stdout to be flushed when an input function is called, such as scanf(), regardless of whether a newline was output prior to the call or not. This ensures that all appropriate output is displayed before the input operation takes place. Therefore, the update might have broken something in Xcode. Although I'm not currently sure what the exact nature of the problem is, a (temporary) workaround is to run your application on the command line. This has worked for my projects. It also reveals that this problem is with the Xcode output window, and not the compiler or something else.
In response to tell's comment: no, flushing stdout does not correct the issue within Xcode. This implies even more strongly to me that the issue is definitely in the Xcode interface itself. When running the application from the command line, calls to fflush() work as expected.
Also, printing to stderr makes no difference from within Xcode. Basically, stdout should be flushed in this case without appealing to stderr or any other gimmicks because the OP is calling scanf(). It works perfectly from the command line... just not in the Xcode output window.
And please note this this question is not a duplicate: it has nothing to do with anyone's misunderstanding of how C input and output work, and everything to do with the fact that a recent update to Xcode broke something.
EDIT:
Thanks, joe_04_04. The update certainly seems to have fixed the problem.
Using cout needs a little bit more time to output the statement which isn't good for me. But when using cerr the output is faster. Why?
Just trying to help :
- cout -> Regular output (console output)
- cerr -> Error output (console error)
cout is buffered, cerr is not, so cout should be faster in most cases. (Although if you really care about speed, the C output functions such as printf tend to be a lot faster than cout/cerr).
cout and cerr are ostream objects. You can call rdbuf() on them to redirect their output independently wherever you want, from within the application. You can open a network socket, wrap it in a stream buffer and redirect there, if you want.
By default, cout is tied to the application's standard output. By default, the standard output is the screen. You can direct the OS to redirect stdout elsewhere. Or it might do it by itself - the nohup utility in Linux, for example, does. Services in Windows also have their standard streams redirected, I think.
And, cerr are tied to the application's standard error. By default the standard error is the screen. You can again redirect stderr elsewhere.
Another issue here is that clog, by default, is buffered like cout, whereas cerr is unit-buffered, meaning it automatically calls flush() after every complete output operation. This is very useful, since it means that the output is not lost in the buffer if the application crashes directly afterwards.
If you run a program like this:
yourprog > yourfile
What you write to cout will go to yourfile. What you write to cerr will go to your screen. That's usually a good thing. I probably don't want your error messages mixed in with your program output. (Especially if some of your error messages are just warnings or diagnostic stuff).
It's also possible to redirect cout to 1 file, and cerr to another. That's a handy paradigm: I run your program, redirect output to a file, error messages to a different file. If your program returns 0 from main, then I know it's OK to process the output file. If it returns an error code, I know NOT to process the output file. The error file will tell me what went wrong.
reference :
- http://www.tutorialspoint.com/cplusplus/cpp_basic_input_output.htm
- http://cboard.cprogramming.com/cplusplus-programming/91613-cout-cerr-clog.html
I have a code that use popen to execute a script ,It works fine but randomly it's blocking and getting CPU to 100% ,after a little investigation I discover that it hangs on popen calls. I have put a printf after the popen showing the descriptor asigned and in this case when it blocks this printf never shows.
What can cause popen to block?
Edit: Code
FILE* pipe = popen(cpCommand, "r");
printf(....
if (pipe)
{
while (!feof(pipe))
{
if (DataReady(fileno(pipe),2500)>0)
{
if (fgets(output,sizeof(output),pipe) != NULL)
{
DataReady is just a select..
I have done a strace after it blocks and it seems to not doing anything
Not an answer ;-)
Try use strace to what it's doing and which syscall hangs.
Tterminal output is line-buffered, so make sure to flush output by using fflush() or using a newline (fflush(stdout); or printf("Debug text\n");) to ensure it doesn't really call the printf().
Run the script manually and ensure the script doesn't hang intermittently before suspecting popen().
Check the script called by popen() why it doesn't end.
As long a s the script does not end, popen() blocks, will say: does not return, as observed.
I strongly doubt this is a C issue.
I have just upgraded to Xcode 4 and am working in C++ project. I am finding that printf() intermittently fails to complete printing (mid-line) to the Xcode console, and from there on printf() ceases to print anything - even though the application continues to run in debugger.
I suspect Xcode 4's console window is at fault because if I redirect stdout to a file, then logging seems to continue without any problems. That said, if I use following on command line:
tail -f log-out.txt
then there are times when incomplete lines are shown. But this is probably due to some sort of buffering (incomplete flush) because ultimately the lines are complete in the file.
So, I am wondering if anyone has experienced something like this and has an understanding of what's causing freeze in Xcode's console output.
Never actually worked with Xcode, BUT:
Can you show us how your printf calls look like?
The reason why I'm asking is that, if you don't flush your stream, some of the output might not reach the console (as you actually pointed out in the question). The simplest way to do that is to add a newline character at the end of each printf call.
This behavior seems to be intermittent and reportedly pre-exists Xcode 4. As a work-around I did something like this to the main() function. There are some advantages to this approach when Xcode's Debug Console is misbehaving.
#define REDIRECT_STDOUT_TO_FILE 1
int main(int argc, char ** argv)
{
#if REDIRECT_STDOUT_TO_FILE //## redirect stdout to "log-out.txt"
freopen("log-out.txt", "w", stdout);
#endif // REDIRECT_STDOUT_TO_FILE
MyApp app(argc, argv);
int result = app.Run();
#if REDIRECT_STDOUT_TO_FILE //## redirect stdout to "log-out.txt"
fflush(stdout);
fclose(stdout);
#endif // REDIRECT_STDOUT_TO_FILE
return result;
}
Using tail -f log-out.txt in Terminal allows one to view stdout output. Or, if you use BBEdit, bbedit --new-window log-out.txt is also an workable solution.
For now, I am considering this a bug in Xcode - and I will continue trying to understand under what conditions it occurs.