[Rxtx] well known disconnect and crash problem

[Jason Sachs]

>Here is:
>http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html
>and next one with small improvement.
>
>Regards
>Mariusz

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.