This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Steps to reproduce: - create Welcome sample project - open Project Properties->Running and set "Console Type" to "Output Window (output only)" - run the project, console output is redirected to the "Output Window", everything is OK - start debugger Result: No console output is appeared in the "Output Window". If I add "fflush(stdout);" before the return statement then output appears in gdb-cmdsXXXX.log file that is removed after closing IDE. So user can not use "Output Window" to observe program results while debugging.
When gdb is run in gdb/mi mode (the mode we run in), it doesn't output either stdout or stderr (I know this sounds brain-dead, but its true!). The only exception to this is when gdb/mi is run in remove mode (which doesn't meet other requirements for this product). I'm downgrading to P3. In the next release, we should probably either always run in a term (Console Type == External Terminal) regardless of the Console Type setting, or post a warning that debugging with Console Type set to Output Window implies no I/O of any sort (there are cases where this is useful). Since the default Console Type is External Terminal in NB 6.0, most users won't run into this problem.
For NetBeans 6.1 we will need to make the change proposed by Gordon.
Fixed in http://hg.netbeans.org/main?cmd=changeset;node=e891805e9550.
Console output while debugging does not appear. The second attempt to start debug session (when the first one finished) hangs IDE.
IDE hangs only if I use in code "fflush(stdout)" command. It does not depend on using terminal or output window.
Alexander, the way I understand you're last 2 comments (from 12 Feb) is that the IDE hangs if you add "fflush(stdout)" to your program and that this happens with both an external terminal or outputting to the output window. Is this correct? Also, what platform(s) do you see this behavior on? I just finished testing on Windows, Solaris, and Ubuntu and had no IDE hangs. If you can repeat this, please post a set of steps I can try (I used Args with a fflush(stdou) added before the return statement).
Output isn't being flushed at a breakpoint because gdb isn't doing it. Since stdout isn't a variable (its a #define), I can't add a gdb command to fflush(stdout). I tried fflush(&__iob[1]) but it also failed. Whats strange is if I start gdb in mi mode from a terminal and paste the same set of commands, stdout gets flushed before the breakpoint on the return statement. But doing it from NetBeans it doesn't. I've looked through gdb docs and there is no way to force a flush. I'll email the gdb forumn for ideas...
After discussion with the gdb developers, the problem is that libc line-buffers stdout if its a tty and block buffers if not. So when I run gdb from a terminal (even in mi mode) I get line buffering and output is flushed before stopping at a breakpoint. If I run the same example in the IDE, output isn't line buffered and the output happens after the breakpoint. I'm going to ask the gdb developers if they'll accept an option to force line buffering. That would be a solution for future releases of gdb, but there isn't anyway to get such a fix backported. Alexander wants this feature disabled for NB 6.1. We'll discuss this next week, before making a final NB6.1 decision.
Since this issue was about adding a feature (output to the console window) I'm closing it as fixed. I've opened 129586 to track the stdout flushing problem in a separate issue. The solution to that issue will be visible (including the IZ number) in NetBeans distributions, so I'd prefer an issue directly pertaining to the current problem.
verified in build 20080321