Core: triangle example crashes at runtime on wayland with segmentation fault. #1275
Labels
No labels
CI
all
basisu
blog
bug
build
contributor-friendly
core
correctness
deferred
dev
direct3d-headers
docs
driver-os-issue
duplicate
dxcompiler
editor
examples
experiment
feature-idea
feedback
flac
freetype
gamemode
gkurve
glfw
gpu
gpu-dawn
harfbuzz
help welcome
in-progress
infrastructure
invalid
libmach
linux-audio-headers
long-term
mach
mach.gfx
mach.math
mach.physics
mach.testing
model3d
needs-triage
object
opengl-headers
opus
os/linux
os/macos
os/wasm
os/windows
package-manager
priority
proposal
proposal-accepted
question
roadmap
slipped
stability
sysaudio
sysgpu
sysjs
validating-fix
vulkan-zig-generated
wayland-headers
website
wontfix
wrench
www
x11-headers
xcode-frameworks
zig-update
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
hexops/mach#1275
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@nippi05 Would you be able to confirm that https://github.com/hexops/mach/pull/1289 fixes this issue?
@RonaldZielaznicki I'm still getting the same error 😕
@nippi05
Hrrrm. And just to cover the bases, this is while running the latest main? Or are you running 4.0?
@RonaldZielaznicki yes master.
which compositor are you using?
also try running it with WAYLAND_DEBUG=1 as an environment variable
another thing is you're running 0.13.0-dev.351+64ef45eb0, try the mach nominated zig version
It's gnome so Mutter(?). I'm using mach nominated version here is output with WAYLAND_DEBUG=1:
it looks like its trying to set the decoration mode using the xdg-decoration protocol but that protocol is not implemented by mutter, so its just trying to access a out of bounds memory address, and it segfaults.
unfortunately unless gnome implements the protocol and provides server side decoration, which is unlikely , mach might have to provide some sort of client side decoration in order to work on fully gnome
these are basically the options:
undesirable for mach devs, would probably mean adding libdecor or something like that
undesirable for gnome devs, unlikely due to philosophical differences
zxdg_decoration_manager_v1exists before callingc.zxdg_decoration_manager_v1_get_toplevel_decoration()would break window moving and resizing, kinda hacky, undesirable for everyone
Thank you for the insight dysphoriac. And ain't that just frustrating, looks like we're betweeen a rock and a hard place here. Checked in on the docs for the protocol, and they've a helpful graphic.
@slimsag Mind if I ask your opinion on what direction we'd like to go?
I believe that GLFW also uses libdecor by default, falling back to SSD only if libdecor is not found.
I think we should do the same here. And, obviously, we should std.DynLib the dependency on libdecor and not rely on system headers for compilation so that cross compilation works.
If libdecor is not available, we should fallback to SSD. If SSD is not available, then let's exit with an error message telling the user their OS is broken and to install libdecor - rather than e.g. having an unresizable window
Think as a stopgap, I'll throw up a PR that'll give a proper error if SSD is not supported.
That way we'll stop getting new/similar reports about if while libdecor is hooked up.
That sounds perfect