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.
| Summary: | standard output from native libraries is not written in realtime in the output window | ||
|---|---|---|---|
| Product: | projects | Reporter: | marcopar <marcopar> |
| Component: | Ant | Assignee: | Jesse Glick <jglick> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | ||
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 68770 | ||
| Bug Blocks: | |||
stdout is usually buffered, I guess you should call fflush(). 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... 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. 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). 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: http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg01166.html See also: http://www.netbeans.org/issues/show_bug.cgi?id=120647 http://www.netbeans.org/issues/show_bug.cgi?id=129586 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. 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. |
Crate a native library with a method: void saluta() { printf("ciao\n"); } 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.