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.

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

Crash on restart #3764

Open
3ach opened this issue Aug 12, 2019 · 5 comments

Comments

@3ach
Copy link

commented Aug 12, 2019

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

After changing screen layout with autorandr or arandr, a i3-msg restart or bindsym ... restart will permanently crash i3. Backtrace says 'No stack.'

Expected Behavior

i3 restarts

Reproduction Instructions

  1. Connect to DisplayLink dock
  2. autorandr --force to create two-screen layout
  3. i3-msg restart

Environment

Output of i3 --moreversion 2>&-:

i3 version: Binary i3 version:  4.17-5-g3b88e41d (2019-08-08, branch "next") © 2009 Michael Stapelberg and contributors
(Getting version from running i3, press ctrl-c to abort…)
Running i3 version: 4.17-5-g3b88e41d (2019-08-08, branch "next") (pid 15890)
Loaded i3 config: /home/zach/.config/i3/config (Last modified: Wed 03 Apr 2019 01:29:49 AM MDT, 11376730 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

My config

Logfile

- Linux Distribution & Version: Arch w/ kernel version 5.2.8
- Are you using a compositor (e.g., xcompmgr or compton): maybe compton but I think it's off
@orestisfl

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

You probably need to run echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope first and then acquire the backtrace.

orestisfl added a commit to orestisfl/i3 that referenced this issue Aug 13, 2019

Move content for non-existing outputs
Probably fixes various related issues:
Closes i3#2276
Closes i3#2459
Closes i3#2936
Closes i3#3764
Closes i3#3765
Closes i3#3766

Tested using
bindsym $mod+Shift+i exec xrandr --output DVI-D-0 --mode 1920x1080 --pos 0x0 --rotate normal --output DVI-I-1 --off, restart

The core issue here is that the JSON read during a restart might contain
invalid outputs when the new process is done reading it.
@orestisfl orestisfl referenced a pull request that will close this issue Aug 13, 2019

orestisfl added a commit to orestisfl/i3 that referenced this issue Aug 13, 2019

Move content for non-existing output containers
Probably fixes various related issues:
Closes i3#2276
Closes i3#2459
Closes i3#2936
Closes i3#3764
Closes i3#3765
Closes i3#3766

Tested using
bindsym $mod+Shift+i exec xrandr --output DVI-D-0 --mode 1920x1080 --pos 0x0 --rotate normal --output DVI-I-1 --off, restart

The core issue here is that the JSON read during a restart might contain
invalid outputs when the new process is done reading it.
@slang800

This comment has been minimized.

Copy link

commented Aug 14, 2019

I think I am getting the same issue.

This is my version (I'm using i3-gaps):

Binary i3 version:  4.17 (04.08.2019) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.17 (04.08.2019) (pid 1168)o abort…)
Loaded i3 config: /home/slang/.config/i3/config (Last modified: Wed 29 May 2019 11:54:01 AM CDT, 6668369 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

And this is my kernel version:

$ uname -r
5.2.8-arch1-1-ARCH

I start up i3 normally, and reloading works as expected. However, if I run this command to arrange my monitors:

xrandr --output VIRTUAL1 --off --output eDP1 --primary --mode 2560x1600 --pos 2432x2160 --rotate normal --output DP1 --scale 1.5x1.5 --mode 1920x1200 --pos 3840x360 --rotate normal --output DP2 --mode 3840x2160 --pos 0x0 --rotate normal
i3-msg restart

Then restarting i3 with $mod+Shift+r will cause a crash that looks like this:

IMG_20190814_155644

Strangely, and unlike @3ach, running i3-msg restart does not cause a crash, only the $mod+Shift+r keys do that for me.

After i3 crashes, neither a regular restart nor a restart while forgetting the layout will fix it.

This is the backtrace I get after running the command that @orestisfl suggested:

#0  0x00007f013a9865f8 in waitpid () at /usr/lib/libpthread.so.0
#1  0x0000560122e72aad in handle_signal ()
#2  0x00007f013a986d00 in <signal handler called> () at /usr/lib/libpthread.so.0
#3  0x00007f013a7e8755 in raise () at /usr/lib/libc.so.6
#4  0x00007f013a7d3851 in abort () at /usr/lib/libc.so.6
#5  0x00007f013a7d3727 in _nl_load_domain.cold () at /usr/lib/libc.so.6
#6  0x00007f013a7e1026 in  () at /usr/lib/libc.so.6
#7  0x00007f013aae0bba in  () at /usr/lib/libev.so.4
#8  0x00007f013aae20f6 in ev_run () at /usr/lib/libev.so.4
#9  0x0000560122e3e571 in main ()
A debugging session is active.

	Inferior 1 [process 826] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 826) detached]

And this is my log file: https://logs.i3wm.org/logs/5681158754926592.bz2.

@pantherman594

This comment has been minimized.

Copy link

commented Aug 18, 2019

I'm getting the same issue.

Also using i3-gaps. Crashes whether external monitors are plugged in or not, and with both a custom config and no config at all (default).

It happens when I restart with the keybinding after using i3-msg restart. I can use either independently as many times as I want, but once I use i3-msg restart i3 crashes the next time I use the keybinding to restart.

For the moment I've changed the keybinding from

bindsym $mod+Shift+r restart

to

bindsym $mod+Shift+r exec i3-msg restart

and it seems to work fine.

Backtrace (almost identical to @slang800's):

#0  0x00007fd9287f55f8 in waitpid () at /usr/lib/libpthread.so.0
#1  0x0000562b9ded6aad in handle_signal ()
#2  0x00007fd9287f5d00 in <signal handler called> () at /usr/lib/libpthread.so.0
#3  0x00007fd928657755 in raise () at /usr/lib/libc.so.6
#4  0x00007fd928642851 in abort () at /usr/lib/libc.so.6
#5  0x00007fd928642727 in _nl_load_domain.cold () at /usr/lib/libc.so.6
#6  0x00007fd928650026 in  () at /usr/lib/libc.so.6
#7  0x00007fd92894fbba in  () at /usr/lib/libev.so.4
#8  0x00007fd9289510f6 in ev_run () at /usr/lib/libev.so.4
#9  0x0000562b9dea2571 in main ()
A debugging session is active.

	Inferior 1 [process 6627] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 6627) detached]

Log: https://logs.i3wm.org/logs/5766460328640512.bz2

@orestisfl

This comment has been minimized.

Copy link
Member

commented Aug 18, 2019

@pantherman594

This comment has been minimized.

Copy link

commented Aug 18, 2019

That did not fix the problem.

This problem did not exist in 4.16 or earlier. After reverting e4ed2a7 it seemed to work again.

pantherman594 added a commit to pantherman594/i3 that referenced this issue Aug 18, 2019

@pantherman594 pantherman594 referenced a pull request that will close this issue Aug 18, 2019

pantherman594 added a commit to pantherman594/i3 that referenced this issue Aug 18, 2019

pantherman594 added a commit to pantherman594/i3 that referenced this issue Aug 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.