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 33384 - Calling readline() on STDIN exibits race conditions
Summary: Calling readline() on STDIN exibits race conditions
Alias: None
Product: cnd
Classification: Unclassified
Component: Terminalemulator (show other bugs)
Version: 3.x
Hardware: PC OS/2
: P3 blocker (vote)
Assignee: issues@platform
Depends on: 28297
  Show dependency tree
Reported: 2003-05-04 07:41 UTC by _ gtzabari
Modified: 2008-12-22 20:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Testcase (725 bytes, text/plain)
2003-05-04 07:42 UTC, _ gtzabari

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2003-05-04 07:41:27 UTC
dev build 200305030100
Sun JDK 1.4.1

Run the attached testcase under command-line and
under the Netbeans terminal emulator. You will
notice that the testcase always runs fine under
cmdline but seems to exibit race conditions under
the terminal emulator.

Expected behavior:

1) Upon getting the "prompt>", type "test<enter>"
2) App will then respond: "got: test" and terminate

Actual behavior:

1) If "test<enter>" is entered quickly, the
correct behavior occurs.
2) If you wait 3 seconds before entering
"test<enter>", in.readLine() never seems to
terminate so the app keeps on taking in input forever.

See attached testcase.
Comment 1 _ gtzabari 2003-05-04 07:42:08 UTC
Created attachment 10215 [details]
Comment 2 _ tboudreau 2003-05-12 15:21:26 UTC
Adding Ivan to cc.
Comment 3 ivan 2003-05-15 02:19:43 UTC
Is the OS truly OS/2?
Is it _only_ failing on OS/2?
Can you reproduce this on some other more easily available platform?
Is this happening with internal or external execution? Both?

Comment 4 _ gtzabari 2003-05-15 06:58:39 UTC
OS is really OS/2 :)
Executation is external.
Please try reproducing this on your machine as I don't have Windows
handy here. If you still can't reproduce it on your end I will
investigate it further under OS/2.

Comment 5 ivan 2003-05-15 18:52:49 UTC
I can't reproduce it on Solaris and I don't have access to
an OS/2 machine, nor even easy access to windows :-(.

I can give you some guidelines as to what to look for:
In org.netbeans.core.output.OutputTabTerm is a nested class
TIListener with methods sendChar() and sendChars().
When you type input these methods should be called.

These in turn calls which will
get buffered in the pipe. The other side of the pipe is 
inReader which is returned by OutputTabTerm.getIn().
This inReader gets connected to some thread in the Executor module 
that has a worker thread (I think) that passes on the characters
from the pipe to the externally executing child process.

My suspicion of the race condition would therefor be in how
the Executor module sets up these connections, but we should
frst double-check that Term and OutputTabTerm actually pass on the
typed characters to the pipe/
Comment 6 _ tboudreau 2003-09-09 05:34:16 UTC
Ivan - do you want to take this issue?  I don't know as much about
the problem, and it sounds like you've at least looked at it.

Comment 7 _ tboudreau 2003-11-16 10:54:01 UTC
Clearing STARTED status on this issue - nobody here has an OS/2
machine to test against, so I'm not going to be able to work on this.  

If and when OutputTabTerm is rewritten (see issue 28297), the problem
will probably clear up - the current code is over-synchronized. 
Comment 8 _ tboudreau 2004-04-19 14:06:12 UTC
Reassigning to Marek, new owner of output window and help system
Comment 9 lkishalmi 2004-08-31 15:43:34 UTC

  Would it make sense to thest this issue against the NB 4.0 dev
builds. I have an OS/2 here. ;-)
Comment 10 mslama 2004-08-31 15:55:20 UTC
Output window is rewritten. Terminal emulator is not used anymore in
NB 4.0. We keep this issue open to track terminal emulator issues.
Comment 11 ivan 2005-03-18 21:25:47 UTC
Got an OK from submitter to close this.
Comment 12 Marian Mirilovic 2005-07-15 14:30:35 UTC