Skip to content
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.

Sign up for GitHub

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

Jump to bottom

sway segfaults on startup #3462

Closed
m0rr1gan opened this issue Jan 18, 2019 · 8 comments · Fixed by #3463
Closed

sway segfaults on startup #3462

m0rr1gan opened this issue Jan 18, 2019 · 8 comments · Fixed by #3463
Labels
bug Not working as intended
Milestone
1.0-rc.1

Comments

@m0rr1gan
Copy link

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
@emersion emersion added the bug Not working as intended label Jan 18, 2019
@emersion emersion added this to the 1.0-rc.1 milestone Jan 18, 2019
emersion added a commit to emersion/sway that referenced this issue Jan 18, 2019
@emersion
Fix crash in cursor_rebase with multiple screens
7428831 
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
@emersion emersion mentioned this issue Jan 18, 2019
Merged
@emersion
Copy link
Member

Can you try #3463?

@emersion
Copy link
Member

emersion commented Jan 18, 2019 •
edited

If it doesn't fix it, please run recompile sway with meson build-asan -Db_sanitize=address && build-asan/sway/sway and upload logs

@mnd999
Copy link

mnd999 commented Jan 18, 2019

Does temporarily commenting out your output lines fix it? I've had the same thing and that fixes it for me.
I am able to add them back in once sway is up and running.

@emersion
Copy link
Member

@mnd999 Please try the PR if you can reproduce the crash.

@mnd999
Copy link

mnd999 commented Jan 18, 2019

@emersion No, that patch doesn't help me either.

My backtrace:

Reading symbols from /home/mark/dev/sway/build/sway/sway...done.
[New LWP 2626]
[New LWP 2632]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `dev/sway/build/sway/sway'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000056339d1498ea in arrange_output (output=0x56339dd87100) at ../sway/tree/arrange.c:243
243		output->lx = output_box->x;
[Current thread is 1 (Thread 0x7eff316ef9c0 (LWP 2626))]
(gdb) bt
#0  0x000056339d1498ea in arrange_output (output=0x56339dd87100) at ../sway/tree/arrange.c:243
#1  0x000056339d119fb4 in arrange_layers (output=0x56339dd87100) at ../sway/desktop/layer_shell.c:180
#2  0x000056339d11c41d in handle_transform (listener=0x56339dd87218, data=0x56339dc83190)
    at ../sway/desktop/output.c:530
#3  0x00007eff33cd307e in wlr_signal_emit_safe (signal=0x56339dc83320, data=0x56339dc83190)
    at ../util/signal.c:29
#4  0x000056339d13181d in apply_output_config (oc=0x56339dc78b80, output=0x56339dd87100)
    at ../sway/config/output.c:226
#5  0x000056339d15529a in output_enable (output=0x56339dd87100, oc=0x56339dc78b80) at ../sway/tree/output.c:81
#6  0x000056339d11c80b in handle_new_output (listener=0x56339d176c58 <server+56>, data=0x56339dc83190)
    at ../sway/desktop/output.c:607
#7  0x00007eff33cd307e in wlr_signal_emit_safe (signal=0x56339db6c008, data=0x56339dc83190)
    at ../util/signal.c:29
#8  0x00007eff33cd307e in wlr_signal_emit_safe
    (signal=signal@entry=0x56339db721e8, data=data@entry=0x56339dc83190) at ../util/signal.c:29
#9  0x00007eff33c9c30d in scan_drm_connectors (drm=<optimized out>) at ../backend/drm/drm.c:1256
#10 0x00007eff33c99183 in backend_start (backend=<optimized out>) at ../backend/drm/backend.c:26
#11 0x00007eff33ca26d6 in multi_backend_start (wlr_backend=0x56339db6bfe0) at ../backend/multi/backend.c:31
#12 0x000056339d118b75 in server_start (server=0x56339d176c20 <server>) at ../sway/server.c:184
#13 0x000056339d1180a6 in main (argc=1, argv=0x7ffc6197bba8) at ../sway/main.c:378

@emersion
Copy link
Member

Ah, you get a different backtrace though. Pushed a new commit, can you try again?

@m0rr1gan
Copy link
Author

Can you try #3463?

This worked for me. Thanks!

emersion added a commit that referenced this issue Jan 19, 2019
@emersion
Fix crash in cursor_rebase with multiple screens
3b7a746 
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
@mnd999
Copy link

mnd999 commented Jan 19, 2019

Same, thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Not working as intended
Milestone
1.0-rc.1
Development

Successfully merging a pull request may close this issue.

Fix crash in cursor_rebase with multiple screens emersion/sway
3 participants
@emersion @mnd999 @m0rr1gan