wl_display@1: error 1: invalid method 9 (since 3 < 4), object wl_surface@25 about wayland-rs

[elinorbgr]

From what I see, wayland-client instanciated a version 3 wl_surface, and the EGL implementation is using it as if it is a version 4, triggering the error.

Could you give me the output of the simple_client example on your system, to confirm?

[nical]

The simple client prints:

Globals advertized by server:
   1 : wl_drm (version 2)
   2 : wl_compositor (version 3)
   3 : wl_shm (version 1)
   4 : wl_output (version 2)
   5 : wl_data_device_manager (version 3)
   6 : gtk_primary_selection_device_manager (version 1)
   7 : zxdg_shell_v6 (version 1)
   8 : wl_shell (version 1)
   9 : gtk_shell1 (version 1)
  10 : wl_subcompositor (version 1)
  11 : zwp_pointer_gestures_v1 (version 1)
  12 : zwp_tablet_manager_v2 (version 1)
  13 : wl_seat (version 5)
  14 : zwp_relative_pointer_manager_v1 (version 1)
  15 : zwp_pointer_constraints_v1 (version 1)
  16 : zxdg_exporter_v1 (version 1)
  17 : zxdg_importer_v1 (version 1)

The simple window example seems to work.

[elinorbgr]

Yeah, that's it. Your compositor exposes wl_compositor version 3 only. However the EGL implementation seems to use version 4 without checking first which version have been bound.

So, depending on how you see things, it's either a bug of mesa for not properly checking the version (but they can also say that they do not support version <4), or a bug of gnome for not supporting version 4 yet.

[nical]

Hopefully there's something we can do about it in glutin? This is on Fedora 25 which has wayland enabled by default and things seem to work (assuming the majority of the gnome apps don't use xwayland by now).

[elinorbgr]

After a quick check, it seems mesa actually does it right (at least on the top of their git).

Which version of mesa are you running?

[elinorbgr]

And which version of wayland C libraries do you have as well?

But, I don't think we can really do anything from glutin to fix this... We can't bind a version 4 object of the server only advertises a version 3, and mesa talks directly to the C lib to figure out the version.

[nical]

Mesa 12.0.3 (on an Haswell integrated gpu).

For the installed wayland libraries I'm not sure how to get the info you want so I tried that:

ldconfig -v | grep wayland
	libwayland-server.so.0 -> libwayland-server.so.0.1.0
	libwayland-client.so.0 -> libwayland-client.so.0.3.0
	libva-wayland.so.1 -> libva-wayland.so.1.3904.0
	libwayland-cursor.so.0 -> libwayland-cursor.so.0.0.0
	libgstwayland-1.0.so.0 -> libgstwayland-1.0.so.0.1000.0
	libwayland-egl.so.1 -> libwayland-egl.so.1.0.0
	libwayland-server.so.0 -> libwayland-server.so.0.1.0
	libwayland-client.so.0 -> libwayland-client.so.0.3.0

[elinorbgr]

Okay. So somehow, the information of the interface version is not correctly forwarded to mesa...

I'll investigate this, thanks for the report.

[elinorbgr]

Can you give me the output of running this code on your system? Tried on mine, and versions are consistent, but maybe something is different on yours? (both version of the compositor and surface should output the same, 3 in your case)

#[macro_use] extern crate wayland_client;

use wayland_client::{EnvHandler, Proxy};
use wayland_client::protocol::wl_compositor;

wayland_env!(WaylandEnv,
    compositor: wl_compositor::WlCompositor
);


fn main() {
    let (display, mut event_queue) = wayland_client::default_connect().unwrap();

    event_queue.add_handler(EnvHandler::<WaylandEnv>::new());
    let registry = display.get_registry().expect("Display cannot be already destroyed.");
    event_queue.register::<_, EnvHandler<WaylandEnv>>(&registry,0);
    event_queue.sync_roundtrip().unwrap();

    let state = event_queue.state();

    let env = state.get_handler::<EnvHandler<WaylandEnv>>(0);
    let surface = env.compositor.create_surface().expect("Compositor cannot be destroyed");
    println!("Compositor version: {}", env.compositor.version());
    println!("Surface version: {}", surface.version());
}

I'm trying to understand if I messed something in the handling of objects versions. If not, I really can't interpret your error in an other way than "it's a bug in your version of mesa" 😐

[nical]

Compositor version: 3
Surface version: 3

[evelikov]

Hi all, mesa person here.

For the sake of me I cannot see how any of this could happen.

Mesa libraries be that libEGL, libgbm, libwayland-egl or the vulkan drivers (libvulkan_*) do not have any references to wl_compositor as the binaries are stripped. Prior to stripping the only one reference is of wl_compositor_interface (due to the extern notation in the wayland header) yet again none of mesa makes use of it or define the interface symbol.
Be that directly (in it's source code) or indirectly (via the generated protocol code and/or the wayland headers).

Skimming through libva and libgst-wayland points out the same thing - zero uses/references.

The only thing which comes to mind is (although unlikely), mismatched libwayland-{client,server}.so binaries. Where one would provide the v3 and another the v4 interface symbol.

[evelikov]

Actually it may be any other library which exports the symbol where it should not have.

I'm not familiar with rust, so it may be that there's something subtle in terms of symbols visibility and friends. I'd suggest tracking where (exactly) each interface defined/exported and which ones get picked -- the ones advertised by the server and picked by the app/library.

[elinorbgr]

What it looks like to me is that, for some reason, wl_proxy_get_version(..) called from rust returns 3 on @nical 's system (as it should, as the interface was instanciated as version 3), while somehow, when mesa calls it here, it returns 4.

Unless maybe for some reason, this mesa was compiled with an erroneous value for WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION ?

[evelikov]

In the fourth comment you mentioned wl_compositor, which confused me a bit.

Barring the wrong version as mentioned by @vberger (should be trivial enough to check with gdb/printf) a couple of ideas come to mind:

There is a MIN() missing from a wl_global_create/wl_registry_bind/wl_resource_create call somewhere, which effectively leads to mesa's wl_surface(s) being v4. Worth tracking down the above three ?

Some [exported,local,other] symbols get messed up and we end up with v4 of wl_surface_interface in Mesa. Worth downgrading to older [v3] wayland and rebuilding mesa/others against it ? Checking the prior idea first is good [imho] since downgrading wayland will only mask that issue.

[elinorbgr]

I mentioned wl_compositor because as wl_surface is created by wl_compositor, it inherits its version number. It was in order to make sure that my crate was indeed using the highest version number available, as I expected it to.

Given the way wayland is designed versioning of the libs and versioning of the protocol are orthogonal. Having a newer wl_surface_interface should not be an issue : versioning of the objects is done at runtime. Even if the compositor advertises a version 4 of an object, I am still able to instantiate it version 1 if I want to. wl_proxy_get_version returns the runtime version of the object. The version of the *_interface symbols only defines the maximum version supported by the lib.

I don't know if mesa creates internal wl_surfaces, or only uses the one provided by the user (my initial assumption was the latter), but anyway, as @nical 's compositor only advertised version 3, it should not be possible for mesa to create a version 4 wl_surface, the wayland libs would refuse it and kill the wayland connection.

Setting a breakpoint on wl_proxy_get_version could give us some insight on what's going on, maybe?

@nical : do you have time to run some debugging tests ?

[emilio]

I also got this message while debugging #79, fwiw.

[emilio]

And the backtrace contained mesa too, but just by chance (I managed to reproduce with and without mesa in the backtrace), because they read the event queue too.

So I suspect it's a similar error, just with a more unfortunate error message.

[emilio]

Nope, it isn't, I get this with upstream, and #79 with a downgraded version of glutin.

[emilio]

So I need to run now, but the error seems to be caused by mesa's wl_display_interface. I may have some more time to investigate tomorrow.

[emilio]

And with seems to be caused, I mean that the closure just called before setting the display error is one where the proxy in wayland's dispatch_event is wl_display_interface, and the implementation display_listener.

[emilio]

Nevermind about mesa, that seems to be wayland's own proxy?

[emilio]

I guess that's the error from the server. Anyway, I'll keep digging tomorrow.

[elinorbgr]

@emilio: what is the smallest example code you can reproduce this error with?

[emilio]

I'm reproducing this with the following glutin example. Note that the size request gets ignored (it always open a fullscreen window).

I haven't tried to minimize it.

Moving the mouse then unfocusing the window with Alt + Tab reproduces the issue consistently.

It also reproduces with LD_PRELOADed debug versions of trunk mesa and wayland.

[package]
# ...

[dependencies]
glutin = "0.7"
gl = "0.6"

extern crate glutin;
extern crate gl;

fn main() {
    let window = glutin::WindowBuilder::new()
        .with_dimensions(2000, 2000)
        .with_title("Splines")
        .build()
        .expect("Couldn't create window!");

    unsafe {
        window.make_current().unwrap();
        gl::load_with(|s| window.get_proc_address(s) as *const _);
        gl::ClearColor(0.0, 1.0, 0.0, 1.0);
        gl::Clear(gl::COLOR_BUFFER_BIT);
        window.swap_buffers().unwrap();
    }

    for event in window.wait_events() {
        unsafe {
            gl::Clear(gl::COLOR_BUFFER_BIT);
        }
        window.swap_buffers().unwrap();
        match event {
            glutin::Event::Closed => break,
            other => {
                println!("Unhandled event: {:?}", other);
            }
        }
    }
}

[elinorbgr]

Okay cool, that is already quite short.

Could you run it with WAYLAND_DEBUG=1 in the environment, reproduce the crash, and post the debug dump here, please?

[emilio]

There it goes: log.zip

I suspect of the damage_buffer call mesa is doing, since it only appears once right before the crash, and it's on the same surface reported by the error. Now, I don't know enough about wayland or mesa to know what's the root cause of it.

[3111980.475] -> [email protected]_buffer(0, 0, 24, 24)
[3111980.823] [email protected](wl_display@1, 1, "invalid method 9 (since 3 < 4), object wl_surface@25")

[emilio]

Oh, also, some other interesting stuff, looking at dmesg, there seems to be a kernel trap? I can reproduce this reliably. Every time, this message appears:

[ 854.272086] traps: splines[31289] trap invalid opcode ip:55a76603465f sp:7ffffc8a4770 error:0
[ 854.272125] in splines[55a765ea0000+267000]

[emilio]

Oh, I got it.

So the missing check is in wayland-window, under set_cursor

[emilio]

There you call damage_buffer, even when the server may not support that opcode, so it seems we should do something like what mesa does, and invalidate the whole surface if the version is less than four.

[elinorbgr]

Oh right, well caught. I'll correct this.

I guess the original crash occured in the swap_buffer for spurious reasons.

[emilio]

I will send you a patch if you want, seems like an easy thing to do after all this debugging shenanigans :P

[elinorbgr]

Don't worry about it, I'm already commiting the fix. Thanks a lot for finding this!

[emilio]

No worries! I just wanted to do my university assignment in Rust ;)

[elinorbgr]

I've released version 0.4.3 of wayland-window, with a bugfix.

@emilio @nical : could you confirm it fixes the crash?

[emilio]

It does for me :)

[nical]

The crash appears to be fixed for me as well. Thank you two for looking into this!

[elinorbgr]

All is good then. :)