[Rxtx] well known disconnect and crash problem

[Jason Sachs]

Yikes: For some reason the email list cut off my message. I did not
mean to sound so brief. Here's the whole message, resent:

> Mariusz -- I've looked at your example quite a bit, and while it is
> fairly robust, it does not solve the problem.
>
> From what I can tell, a crash error occurs under several conditions
> (environment = WinXP SP3, jar=RXTX-2.2pre1, dll=RXTX-2.2pre2),
> including at least the following two. These comments appear to apply
> to the use of RXTX as a whole, not to your specific application.
>
> 1. Opening a port with an out-of-date CommPortIdentifier:
>  a. Application enumerates CommPortIdentifiers to get valid port name Strings
>  b. User unplugs USB comm port (or PC is connected to a device with a
> USB comm port that powers down)
>  c. Application tries to open a comm port with a name of a port that
> was unplugged, e.g.:
>
> String portName = ... // a name of a port that was unplugged
> CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier(portName);
> CommPort commPort = cpi.open(ownerName, timeout);
>
> This case is uncommon but not unreasonably rare. Interactive
> applications may have an "open port" button that can be pressed at any
> time -- in order to avoid the sequence of events above, the
> application would have to rescan ports every time the "open port"
> button has been pressed, and immediately open the port thereafter.
>
> 2. Writing to a disconnected port
>  a. Application successfully opens a port and reads/writes to it
>  b. User unplugs USB comm port
>  c. Either of the following:
>      i. Application catches an IOException on read/write threads, and
> stops using the port, so that the threads run to completion. It looks
> like RXTX still has some kind of native background thread that keeps
> trying to access the port and that crashes the JVM.
>      ii. Application catches an IOException on read/write, and tries
> to close the port while RXTX is still writing data in the native
> background thread. This crashes the JVM.
>
> If an application does not write to the port often, it is possible (as
> your application demonstrates) to catch an IOException in a blocking
> call to InputStream.read(), and successfully close the port before
> RXTX can crash the JVM. But if the application does send frequent data
> to the serial port, and the USB port is unplugged, there doesn't seem
> to be a way to stop the JVM from crashing.
>
> Mariusz: Your application does not write enough characters to the port
> to cause this to occur. I have an updated application based on yours
> which does (it attempts to send 1024 characters every time the user
> hits Enter). It occurs whether I use write(byte[]) with a byte array
> or write(byte) for a single byte. I can send you this later when I
> have time.
>
> I will file a more detailed bug report for the rxtx bug tracker when I
> get back from vacation.
>
> --Jason
>
> p.s. just so you know, you have a few concurrency errors in your
> application. You've got synchronization locks around some but not all
> of the uses of your variables stopRead and stopWrite. (which
> technically should be instance and not static variables, as this
> breaks if you have more than one instance of the main class) It would
> be better and easier to use a single AtomicBoolean or a CountdownLatch
> that represents both read and write access to the port. Or just use a
> pair of synchronized settter/getter methods around a private boolean
> which is not accessed except through the setter/getter methods.
>