Server side objects give protocol designers exciting ways to break clients.
For example, if a client deletes an object at the same time the server is
sending an event containing a new object to that object, then we currently
silently drop that event. If a following event in the buffer from an
object that has not yet been deleted also contains a new object, the wl_map
constraint that new objects must be 1 higher than the current highest
object count is violated. This results in a disconnect.
Instead, let's augment the zombie accounting code to keep the entire proxy
around on deletion, for both client and server generated objects.
This way we can create and immediately delete objects that are destined for
zombie proxies - thus creating zombie descendants.
We can go no further to clean this up in the client library - we can't call
a destructor because the protocol might dictate that child objects will be
automatically destroyed on the destruction of the parent.
So we turn a situation that would lead to an erroneous disconnect into one
that may or may not leak object ids depending on protocol definition.
Fixes#74
for some definition of "fix" anyway.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is the style used in wayland.xml which is the only file we really
care about for git blame information. So let's adjust all others to that
style for consistency and fix editorconfig to avoid messing this up in
the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Until recently, if an event attempting to deliver an fd to a zombie
object was demarshalled after the object was made into a zombie, we
leaked the fd and left it in the buffer.
If another event attempting to deliver an fd to a live object was in that
same buffer, the zombie's fd would be delivered instead.
This test recreates that situation.
While this is a ridiculously contrived way to force this race - delivering
an event from a destruction handler - I do have reports of this race
being hit in real world code.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Until recently, if a client destroying a resource raced with the
server generating an event on that resource that delivered a file
descriptor, we would leak the fd.
This tests for a leaked fd from that race condition.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
