We have quite many assumptions for libwayland-client users:
- when a wl_event_queue is destroyed, we assume (or do we?) there are no objects on it
- what happens if you destroy a wl_event_queue that has queued events?
- Or move an object to a different queue while old queue has events?
- when a wl_display is destroyed, all objects, event queues etc. referencing it have already been destroyed
- the argument objects of a request come from the same wl_display as the object itself
- when you pass in two things, like wl_display and wl_event_queue, to a function as arguments, make sure they are referring to the same wl_display beneath
The checks should be as light-weight as possible. If a thing does not already have a list of all other things referencing it, we don't want to add a list just for the checking, I assume. Although, that probably would ease debugging... OTOH, Valgrind should be able to give the same information. Counters should be enough, preferably protected by existing mutexes that are already taken on that code path anyway.
The reaction to a detected error should be abort(). Using an object from a wrong wl_display is a bug right at that point. Destroying a thing that is still being used - you cannot pick between not destroying it and destroying it anyway, so better just stop right there.
These sanity checks should be accompanied by tests that trigger them.