Skip to content

Erroneous type deserialization on some signals #21

@haggish

Description

@haggish

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions