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.

Bug 147099

Summary: standard output from native libraries is not written in realtime in the output window
Product: projects Reporter: marcopar <marcopar>
Component: AntAssignee: Jesse Glick <jglick>
Severity: blocker    
Priority: P3    
Version: 6.x   
Hardware: All   
OS: Linux   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 68770    
Bug Blocks:    

Description marcopar 2008-09-12 15:06:22 UTC
Crate a native library with a method:

void saluta() {

call it from java via JNI.

Then create a frame with a button with an action that calls the native method.
Pressing the button you should see "ciao" appearing in the output window but this happens only if:
- you press the button many times 
- exit the java app

so, the stdout from the native app seems to be buffered in some way.

i read something similar was happening when debugging ruby applications but since i don't know ruby and that the
discussions involved the reading of ruby code, i gave up. sorry, i do not remember the link of that discussion.
Comment 1 t_h 2008-09-16 10:01:37 UTC
stdout is usually buffered, I guess you should call fflush().
Comment 2 marcopar 2008-09-18 16:12:05 UTC
maybe but this buffering never caused me problems when developing straight C apps or when executing the java app in a
terminal. a friend using eclipse also says he hasn't this problem with stdout but i've not verified it directly. so it's
strange that this only happens when executing from netbeans.

stderr works as expected so it's a good workaround for libraries developed by me.
the problem remains for 3rd party libraries...
Comment 3 t_h 2008-09-24 10:38:01 UTC
I think it is just std out buffering, I tested it and after fflush(stdout) it works. Anyway there is nothing it can be
done in OW if no text arrives.
Comment 4 Jesse Glick 2008-09-24 16:42:15 UTC
A terminal differs from a pseudotty, maybe that is the difference.

Nothing to be done on NB's side. If it gets output, it shows it; NB has no internal buffering (except in some cases of
partial-line output pending a newline, which is not your case). If you print to stdout you are not guaranteed to see it
at any particular time unless you explicitly flush (or the program exits).
Comment 5 marcopar 2008-09-25 14:36:05 UTC
I did a quick google tour around and i found that probably the problem relies in standard streams buffering mode.
As i understood, in bash at least, stdout is line buffered in a terminal and fully buffered in other cases. On the other
hand stderr is always unbuffered.

This can explain all what i've described.

As a side note i found that exists a function called setvbuf that gives the opportunity to change buffer mode at runtime.
I don't know how Netbeans is launched under Linux and if this function can be called at startup to set stdout to a more
useful buffering mode.

Here you can find a link to a discussion happened few years ago on an eclipse mailing lists and that probably explains
why eclipse does not have this issue:
Comment 6 marcopar 2008-09-25 15:07:17 UTC
See also:

I know that this is all c/c++ modules talking and not strict java talking but the problems are the same once you start
playing with JNI.
Comment 7 Jesse Glick 2008-09-25 19:01:55 UTC
Eclipse apparently uses a special native app to wrap the launch of user programs. NetBeans for now uses plain
Runtime.exec and displays the output. (Actually for now it really goes through Ant, though this may change for projects
using "Compile on Save" in a future release.) While it would be possible to introduce use of a wrapper of this kind, I
do not currently plan on it, but see issue #136929.