NPE in org.freedesktop.dbus.connections.AbstractConnection.internalDisconnect(IOException) prevents JVM shutdown

[GeorgBisseling]

Version dbus-java-core-4.2.1.jar

When experimenting with bluez-dbus I observed that Thread [DBus Sender Thread-1] sometimes inhibits the Java process from terminating cleanly.

There was a pending Connect call to a bluetooth device.

The code in org.freedesktop.dbus.connections.AbstractConnection.internalDisconnect(IOException) is intended to terminate such pending calls.

Unfortunately it is called with _connectionError == null on a regular disconnect. This leads to an NPE and the pending calls are not terminated so that in turn the sender thread is not terminated.

[hypfvieh]

Unfortunately it is called with _connectionError == null on a regular disconnect. This leads to an NPE and the pending calls are not terminated so that in turn the sender thread is not terminated.

Where?

When disconnect() or close() is called, the connection should be closed and all remaining calls should be answered or at least receive an Error. Therefore internalDisconnect() is called with null parameter to signal this is a ordered clean shutdown, no shutdown due to an DBus error.

So when bluetooth is hanging in some sort of timeout and your application quits, dbus-java tries it's best to signal that the requesting endpoint will disconnect now and that all remaining calls are canceled.

The only obvious annoyance here is that the ExecutorService for the Sending-Threadpool create non-daemon threads.
I will change that, there is no reason to use non-daemon threads and block anything.

[GeorgBisseling]

The NPE is actually in the call new Error(mthCall, _connectionError) that is meant to be the reply to the pending call.

[hypfvieh]

That issue was already fixed in commit 814cf56 beginning of this year.
Please upgrade to 4.3.0

[GeorgBisseling]

Ok, 4.3.x works for me.