-
-
Notifications
You must be signed in to change notification settings - Fork 78
Description
I am listening to some signals from DBus, one of them is "ServicesChanged" from Connman, which has a signature of a(oa{sv})ao
.
It seems that the signals that have the first array as empty, and the other array (of object paths) non-empty, result in a ClassCastException
:
2018-07-19 08:17:52 [DBus Worker Thread-3] WARN o.f.d.c.impl.DBusConnection - Exception while running signal handler 'xxx.ConfigurationService$ServicesChangeHandler@38db2f' for signal 'DBusSignal [clazz=class xxx.IDBusConnmanManager$ServicesChanged]': {}
org.freedesktop.dbus.exceptions.DBusException: java.lang.IllegalArgumentException: java.lang.ClassCastException@1858f7
at org.freedesktop.dbus.messages.DBusSignal.createReal(DBusSignal.java:222)
at org.freedesktop.dbus.connections.AbstractConnection$3.run(AbstractConnection.java:772)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException@1858f7
at sun.reflect.GeneratedConstructorAccessor22.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.freedesktop.dbus.messages.DBusSignal.createReal(DBusSignal.java:215)
... 4 common frames omitted
What seems to happen is that while getting the signal constructor parameters in Message.getParameters()
, the array of object paths is interpreted as one object path (the one path value is all the object path strings mangled together plus some garbage inbetween). Then when giving the parameters to Reflection, an exception is thrown as the wrongly deserialized constructor param is ObjectPath
and not List<ObjectPath>
.
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - extract(a(oa{sv})ao,#1194, {0,0}
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - Extracting type: a from offset 0
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - aligning to a
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - Reading array of size: 0
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - aligning to (
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - Aligned type: (oa{sv})ao 8 9
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - Extracted: [] (now at 8)
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - Extracting type: o from offset 8
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - aligning to o
2018-07-19 15:38:20 [DBus Worker Thread-1] TRACE o.f.dbus.messages.DBusSignal - Extracted: I/net/connman/service/wifi_80d21d5f4569_42656c6b696e2e35333945_managed_psk>/net/connman/service/wifi_80d21d5f4569_4755455354_managed_noneU/net/connman/service/wifi_80d21d5f4569_416c6578616e64657273206950686f6e65_managed_pskQ/net/connman/service/wifi_80d21d5f4569_434552545f55505f54455354_managed_ieee8021xQ/net/connman/service/wifi_80d21d5f4569_4c414e2d4e41432d54455354_managed_ieee8021xA/net/connman/service/wifi_80d21d5f4569_4853532d444556_managed_pskE/net/connman/service/wifi_80d21d5f4569_4b6f6e666572656e7a_managed_pskA/net/connman/service/wifi_80d21d5f4569_4553583547487a_managed_psk=/net/connman/service/wifi_80d21d5f4569_4553455854_managed_pskC/net/connman/service/wifi_80d21d5f4569_4553494e54_managed_ieee8021x?/net/connman/service/wifi_80d21d5f4569_776c6e6c6368_managed_psk?/net/connman/service/wifi_80d21d5f4569_hidden_managed_ieee8021x?/net/connman/service/wifi_80d21d5f4569_4c414e_managed_ieee8021x9/net/connman/service/wifi_80d21d5f4569_455358_managed_psk9/net/connman/service/wifi_80d21d5f4569_52494f_managed_pskE/net/connman/service/wifi_80d21d5f4569_434755455354_managed_ieee8021x (now at 1195)
Specifically, after having parsed the empty first array, the second round of extractOne
method for the non-empty object path array is given an offset array which seems to have its first element (signature offset) one element too far and this makes the method try to parse an array of object paths as one. Hence the first round of extractOne
of the two seems to update the offset to a value one too many. When I debug and set the signature offset to a value one less for extractOne
after extracting the empty array, the parameters are deserialized correctly.
This is happening in (little-endian) signals with this exact signature, in 2.7.* and 3.0 both.