-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vkcube crashes on wayland session #1451
Comments
@sergio-fferreira |
No, it doesn't. |
I feel I may be having a similar issue. When trying to run BeamNG on Steam with the Vulkan backend Gamescope doesn't always crash, but may hang indefinitely needing a full reboot, randomly start stuttering, or lead to refresh rate control and other settings being completely broken until reboot. |
@sergio-fferreira well for now, yeah From the log, it looks like gamescope is crashing somewhere (and not the app running under gamescope) Could you please post the coredump message from gamescope, which you can get by running: |
Sure. This is the output of the latest bump (not all bumps):
|
Are you able to get a backtrace with symbols? |
@Joshua-Ashton Apologies for the delay. How can I get a backtrace with symbols? |
I have the same problem, using an AMD RX 6600, so it's not nvidia specific. More information:
I'm trying to backrace with symbols but apparently gamescope build instructions don't seem to work as expected. I don't get a gamescope executable after compiling. |
@unit73e the Gamescope binary gets placed in |
@matte-schwartz thanks Here's what I did:
And finally got this with backtrace:
|
This looks like it's just crashing on shutdown because vkcube didn't open. Do you have vkcube installed? |
@Joshua-Ashton it does open but then again it could be be messing up the backtrace Then I get this after closing vkcube |
OP reported that |
@matte-schwartz you're right, it is the opposite problem. Didn't read carefully enough. With the wayland backend it works perfect for vkcube and friends, except with wine. With wine it gets stuck on exit, that's why I experimented with SDL, and then noticed the core dump. Doesn't really bother me that much except it's filling the disk with logs. I suppose it's a different problem. This should be reproducible with latest Arch packages. |
I tried to reproduce @unit73e steps and running Output
coredumpctl info 6778
coredumpctl debug 6778
Don't hesitate to ask further questions. |
@sergio-fferreira just one additional point, you have ?? in your libc.so.6 traces, and that means it doesn't have debug information on glibc (you do have in gamescope). If you want to add that as well GDB asks at start if you want to download debug info. There are other ways, but that's the easiest. |
Indeed, I noticed, but didn't know how to solve it. Thank you, I will update the results when possible. |
I also tried in a more traditional way of debugging. I think it should give a better picture of what's happening in my case, because we get two backtraces. These steps can be copied as well for @sergio-fferreira case:
Then we close the vkcube window and get:
Then backtrace:
In gamescope it's raising a SIGTERM when it detects a window close event:
And then we can continue and backtrace again:
Here it tries to delete the backend, and then it crashes:
If I had to guess gamescope is not handling the SIGTERM of the vkcube thread, and so we get a SIGABRT, and then a core dump, but that's just my guess. Maybe the object doesn't exist anymore and then it crashes? In my case with AMD + SDL and this thread Nvidia + Wayland. I'm a rusty C/C++ tools but I think I could debug with breakpoints to find out. Either that or someone more experienced with gamescope code will figure it out. EDIT: added code information where relevant |
It's also a good practice to compare with what's not core dumping:
Close window and:
My bug is not the same but it looks related. I'd say do these steps in your machine @sergio-fferreira , it gives a bit more information than I put all the information because I'm aware not everyone is a developer and still want to help. |
@unit73e I had made a pr to fix it, and also fix another segfault on exit that I discovered after fixing the std::terminate issue: #1335 While it is annoying that gamescope sdl is coredumping on exit, to the best of my knowledge, the specific issues causing it to coredump on exit are unrelated to issues w/ gamescope crashing/hanging during runtime. |
Hi @unit73e, here I tried to reproduce your steps in #1451 (comment). Please remember my issue is different from yours. My issue is Using latest master (commit b768e8f).
I don't know why "??" are still appearing... Then isolating where the
With this, and by reading documentation, I believe that gamescope crashes when it can't obtain a display context's file descriptor. Thank you @unit73e for your instructions, I hope the issue is more clear now. |
That abort after wl_display_get_fd was also reported in #1456. I have never run into that abort on the first time the gamescope window opens, on amdgpu/sway. I can only reproduce when it is the second/etc. time the gamescope window opens (for the same gamescope process). |
The line
also seems important. |
Actually that’s pretty much benign |
Alright, sorry. |
When becoming invisible, a NULL buffer is attached to the toplevel's surface which unmaps it. The compositor resets their state and the surface may also be considered unconfigured. Upon becoming visible, the surface must be re-mapped using the same process during initialization (commit without a buffer and wait for configure) before we begin attaching an actual buffer. The default properties should also be recovered. Fixes: ValveSoftware#1456 Fixes: ValveSoftware#1451 (probably) Fixes: ValveSoftware#1488 (probably) Fixes: ValveSoftware#1533
When becoming invisible, a NULL buffer is attached to the toplevel's surface which unmaps it. The compositor resets their state and the surface may also be considered unconfigured. Upon becoming visible, the surface must be re-mapped using the same process during initialization (commit without a buffer and wait for configure) before we begin attaching an actual buffer. The default properties should also be recovered. Fixes: ValveSoftware#1456 Fixes: ValveSoftware#1451 (probably) Fixes: ValveSoftware#1488 (probably) Fixes: ValveSoftware#1533
GPU: integrated AMD + dedicated Nvidia RTX3060 mobile
Desktop: KDE Plasma 6.0.5 Wayland
Running
gamescope vkcube
produces the following output:Gamescope works as expected in a X11 session.
Thanks in advance.
The text was updated successfully, but these errors were encountered: