Comments (37)
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?
from wayland-rs.
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.
from wayland-rs.
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.
from wayland-rs.
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).
from wayland-rs.
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?
from wayland-rs.
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.
from wayland-rs.
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
from wayland-rs.
Okay. So somehow, the information of the interface version is not correctly forwarded to mesa...
I'll investigate this, thanks for the report.
from wayland-rs.
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>>(®istry,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" 😐
from wayland-rs.
Compositor version: 3
Surface version: 3
from wayland-rs.
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.
from wayland-rs.
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.
from wayland-rs.
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
?
from wayland-rs.
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.
from wayland-rs.
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 ?
from wayland-rs.
I also got this message while debugging #79, fwiw.
from wayland-rs.
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.
from wayland-rs.
Nope, it isn't, I get this with upstream, and #79 with a downgraded version of glutin.
from wayland-rs.
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.
from wayland-rs.
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
.
from wayland-rs.
Nevermind about mesa, that seems to be wayland's own proxy?
from wayland-rs.
I guess that's the error from the server. Anyway, I'll keep digging tomorrow.
from wayland-rs.
@emilio: what is the smallest example code you can reproduce this error with?
from wayland-rs.
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_PRELOAD
ed 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);
}
}
}
}
from wayland-rs.
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?
from wayland-rs.
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")
from wayland-rs.
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]
from wayland-rs.
Oh, I got it.
So the missing check is in wayland-window, under set_cursor
from wayland-rs.
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.
from wayland-rs.
Oh right, well caught. I'll correct this.
I guess the original crash occured in the swap_buffer for spurious reasons.
from wayland-rs.
I will send you a patch if you want, seems like an easy thing to do after all this debugging shenanigans :P
from wayland-rs.
Don't worry about it, I'm already commiting the fix. Thanks a lot for finding this!
from wayland-rs.
No worries! I just wanted to do my university assignment in Rust ;)
from wayland-rs.
I've released version 0.4.3 of wayland-window, with a bugfix.
@emilio @nical : could you confirm it fixes the crash?
from wayland-rs.
It does for me :)
from wayland-rs.
The crash appears to be fixed for me as well. Thank you two for looking into this!
from wayland-rs.
All is good then. :)
from wayland-rs.
Related Issues (20)
- Efficient single-threaded client implementation? HOT 3
- compile break in latest release (0.31.1) HOT 4
- `it is undefined behavior to use this value` error on latest nightly compiler HOT 12
- Not compiles on nightly HOT 1
- wayland_client WlBuffer Memory Leak HOT 4
- wayland-client: add easier way to create object from wl_proxy pointer HOT 1
- Proxy tags HOT 3
- wayland-sys vendor feature (request for a `wayland-src` crate) HOT 2
- how to convert a wl_surface pointer to WlSurface HOT 2
- WlRegistry.bind always outputs WlRegistry HOT 5
- Failed build when running with coverage on stable Rust HOT 1
- RFC: Rethinking the design of the crates API HOT 8
- Unable to copy to buffer using ZwlrScreencopyFrameV1 HOT 1
- Apparent misuse of scoped-tls, only appearing on a Raspberry Pi HOT 19
- Feature to avoid usage of `memfd_create` HOT 3
- Backend+client API to take control of proxies HOT 3
- wayland-protocols 0.32 got published without protocols/ HOT 2
- Attaching None to a surface influences surface configuration HOT 3
- illumos is not supported HOT 4
- surface.attach(None, 0, 0) doesn't allow for a re-map of the layer surface. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wayland-rs.