i3: Scratchpad gone and X freeze

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version: 4.13 (2016-11-08) © 2009 Michael Stapelberg and contributors Running i3 version: 4.13 (2016-11-08) (pid 4808)o abort…) Loaded i3 config: ~/.config/i3/config (Last modified: Sat 29 Apr 2017 05:02:35 PM CEST, 2330 seconds ago)

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

URL to a logfile as per http://i3wm.org/docs/debugging.html:

( as it’s caotic I’ll upload the logfile once it ocurred again)

What I did:

Nothing apparently

What I saw:

I’m used to have a terminal in the scratchpad, but I don’t know why sometimes the terminal gets closed and when I open the scratchpad it shows a small (5cmx3cm) black rectangle in the middle of the screen.

The mouse is not able to exit that square and all the bindings stop working, I have to go to a tty and restart the login manager to restart the X.

What I expected instead:

First the scratchpad to be there, and if it got closed don’t crash X

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 32 (14 by maintainers)

Commits related to this issue

Most upvoted comments

Thanks for the updated files. I think I know what’s going on now:

  1. You have a malformed /home/eblau/.config/i3/ws2.json (could you upload that please?):
09/03/2017 10:01:58 AM - ERROR: JSON parsing error: parse error: invalid object key (must be a string)
          : "^browser$"                }             ],             "t
                     (right here) ------^
  1. When loading the file, i3 creates two containers, which are inserted into all_cons.
  2. Parsing the file is aborted, and the two containers are never attached correctly into the hierarchy.
  3. scratchpad show iterates through all containers and tries to find the workspace each container is on. The half-initialized containers result in a crash.

So, I think you should be able to avoid this issue by fixing your layout file.

Here are a few things we could improve:

  1. We should spawn an i3-nagbar instance so that users are alerted about the error in their layout file.
  2. We could parse the JSON twice (once without side effects, then again with side effects).
  3. Possibly we could try to change the code to only ever correctly initialize containers.

@stapelberg I was able to finally get a crash with an i3 log file. Here is a link to it:

https://drive.google.com/open?id=0B6KqqfyfVii_a3h2TUdFcWNseVE

The backtrace is the same as above. Please let me know if there’s anything else needed for this issue. Thanks for taking a look at it!