Add sanity checks for libwayland-client users
Closed, ResolvedPublic


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.

pq created this task.Apr 27 2015, 11:30 AM
pq updated the task description. (Show Details)
pq raised the priority of this task from to Needs Triage.
pq added a project: Wayland.
pq added a subscriber: pq.
pq added a comment.Apr 29 2015, 6:34 AM

Wish list from Olivier Crete:

  • if you can do it without too much overhead, complain about undestroyed objects on a queue?
  • ideally printing of list of objects before aborting would be nice
daniels added a subscriber: daniels.Sep 2 2015, 6:03 PM
pq updated the task description. (Show Details)Oct 12 2015, 9:31 AM
pq triaged this task as Enhancement priority.Oct 12 2015, 10:16 AM

GitLab Migration Automatic Message

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

daniels closed this task as Closed.Jun 5 2018, 7:15 PM
daniels claimed this task.