-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
sway segfaults on startup #3462
Comments
Designing the output configuration sequence without invalid state is tricky. We have one function, apply_output_config, that takes an output and (besides other things) performs a modeset and inserts the output in the output layout. The modeset can fail, in which case we don't want the output to be enabled. We also have an output_enable function, which calls output_apply_config and also configures the output's workspace and inserts it in the root container. Now, we have two choices. Either we configure the output before it's been inserted in the root container and then, if the modeset was successful, we insert it and create the workspace. The main issue with this approach is that configuring the output triggers a handful of signals, namely wlr_output.mode and wlr_output_layout.change. In those event handlers, we need to make sure to ignore these outputs in the process of being configured. Either we first insert the output, create the workspace and then try to configure it. It means we need to undo everything if the modeset fails. The main issue with this solution is that it enables and disables the output very quickly, creates a workspace and immediately destroys it, and maybe moves views back and forth (see output_evacuate). I've tried to make it so an output isn't enabled then immediately disabled. We already have code for ignoring outputs when the output is being destructed. Fixes swaywm#3462
Can you try #3463? |
If it doesn't fix it, please run recompile sway with |
Does temporarily commenting out your output lines fix it? I've had the same thing and that fixes it for me. |
@mnd999 Please try the PR if you can reproduce the crash. |
@emersion No, that patch doesn't help me either. My backtrace:
|
Ah, you get a different backtrace though. Pushed a new commit, can you try again? |
This worked for me. Thanks! |
Designing the output configuration sequence without invalid state is tricky. We have one function, apply_output_config, that takes an output and (besides other things) performs a modeset and inserts the output in the output layout. The modeset can fail, in which case we don't want the output to be enabled. We also have an output_enable function, which calls output_apply_config and also configures the output's workspace and inserts it in the root container. Now, we have two choices. Either we configure the output before it's been inserted in the root container and then, if the modeset was successful, we insert it and create the workspace. The main issue with this approach is that configuring the output triggers a handful of signals, namely wlr_output.mode and wlr_output_layout.change. In those event handlers, we need to make sure to ignore these outputs in the process of being configured. Either we first insert the output, create the workspace and then try to configure it. It means we need to undo everything if the modeset fails. The main issue with this solution is that it enables and disables the output very quickly, creates a workspace and immediately destroys it, and maybe moves views back and forth (see output_evacuate). I've tried to make it so an output isn't enabled then immediately disabled. We already have code for ignoring outputs when the output is being destructed. Fixes #3462
Same, thanks! 👍 |
Sway segfaults when starting from a tty with default config file.
sway -v:
sway version 1.0-beta.2-218-g60220fce (Jan 18 2019, branch 'master')
sway -c /etc/sway/config -d:
https://ptpb.pw/3N5G
coredump gdb sway and bt full:
https://ptpb.pw/90TY
I am running the latest version of sway and wlroots.
#3460 does not fix this for me
The text was updated successfully, but these errors were encountered: