Bug 66830

Does the tree you're testing with contain the following fix:

commit aaadc774a7a0cdb4b377d37608e554f470c67d57
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Mon Jul 8 16:20:31 2013 -0400

    input: Remove wl_seat global when a seat is destroyed
    
    The input code was relying on compositor destruction to clean up the
    global, but that doesn't work when the global comes and goes dynamically.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=65913

?

nope, it doesn't.
I use git master and 'git show aadc774a7a0cdb4b377d37608e554f470c67d57 -- ' returns:
fatal: bad revision 'aadc774a7a0cdb4b377d37608e554f470c67d57'

in both wayland and weston.

Sorry, my mistake - I didn't copy whole commit id.
Yes I have this commit in weston.

rdp_client_activity function in weston/src/compositor-rdp.c frees rdp peer context and rdp peer, which in turn release weston structures e.g. wl_seat

the problem is these structures can still be in use e.g. in registry_bind in wayland-server.c which calls bind_seat with zeroed or often garbage wl_seat.

it's easily reproduceable (at least for me, running under X) with rdesktop :

./weston -Brdp-backend.so

for x in `seq 0 100`; do rdesktop -b -4 127.0.0.1 & done ; killall rdesktop


below is example of contents of wl_seat structure passed to bind_seat:

{base_resource_list = {prev = 0x0, next = 0x0}, global = 0x0, pointer = 0x0, keyboard = 0x0, touch = 0x0, output = 0x0, 
  destroy_signal = {listener_list = {prev = 0x0, next = 0x0}}, compositor = 0x0, link = {prev = 0x31, next = 0x74ef80}, 
  modifier_state = (unknown: 8153568), saved_kbd_focus = 0x75ef7f, saved_kbd_focus_listener = {link = {prev = 0x74ef80, next = 0x0}, 
    notify = 0x6a1}, drag_resource_list = {prev = 0x0, next = 0x6599d0}, selection_serial = 0, selection_data_source = 0x0, 
  selection_data_source_listener = {link = {prev = 0x0, next = 0x0}, notify = 0x0}, selection_signal = {listener_list = {prev = 0x0, 
      next = 0x0}}, num_tp = 0, led_update = 0x0, xkb_info = {keymap = 0x0, keymap_fd = 0, keymap_size = 0, keymap_area = 0x0, 
    shift_mod = 0, caps_mod = 0, ctrl_mod = 0, alt_mod = 0, mod2_mod = 0, mod3_mod = 0, super_mod = 6658800, mod5_mod = 0, 
    num_led = 0, caps_led = 0, scroll_led = 0}, xkb_state = {state = 0x0, leds = (unknown: 0)}, input_method = 0x0, 
  seat_name = 0x65b4a0 "\220>i"}


base_resource_list has NULL in prev and next, which should never happen, unless we're just after calloc/memset or when we removed head of the list (wl_list_remove(&seat->base_resource_list) somewhere).

Hardening, do you have any thoughts on this issue?

I think it is a duplicate of #81041, the backtrace is almost the same. I didn't manage to reproduce it here but i've found other bugs when trying. 

With KRH we had marked it resolved/confirmed as i couldn't reproduce it, we probably should be reopen it.

(In reply to comment #6)
> I think it is a duplicate of #81041, the backtrace is almost the same. I
Sorry it is bug #65913

> didn't manage to reproduce it here but i've found other bugs when trying. 
> 
> With KRH we had marked it resolved/confirmed as i couldn't reproduce it, we
> probably should be reopen it.

Looking carefully at this backtrace, at line 727 (first harmfull notice) my impression is that a client (most probably weston-keyboard) tries to bind a seat that has been released on the server side.

Created attachment 83337 [details]
Easy to reproduce with 2 consecutive rdesktops

The backtrace  "Easy to reproduce with 2 consecutive rdesktops" is really easy to trigger.

* in weston.ini disable modules, give a bad path for weston-keyboard
* Connect / disconnect a first rdesktop
* Connect / disconnect again rdesktop and you got it

I've just sent a patch to the ML to release the keyboard and the pointer before releasing the seat.

Assuming this was fixed by the patch.