Losing keyboard on Debian Jessie

[steveklabnik]

I run pretty basic Debian Jessie on my ThinkPad, and wtftw seems to have a weird behavior: after a while, the only thing that can use the keyboard is firefox.

Steps:

1. Use wtftw for a while. Everyhing works just fine.
2. at some point, bad stuff happens
3. Notice that you can't switch workspaces, use xmobar, or even quit. Typing in text boxes in Firefox works, though.

I'm using the stock config file, just pointing at my own xmobarrc.

[Kintaro]

Could you run it again with the current code and RUST_LOG="debug"? As it's difficult to grab the output, it also writes it to ~/.wtftw.log

The output would interest me. The events in the main loop should give me a clue (I hope).

[steveklabnik]

How do I do that? LIke this:

exec RUST_LOG="debug" /home/steve/blah/target/wtftw

?

[Kintaro]

Never tested it that way. Could be either like you said, or

RUST_LOG="debug" exec /home/steve/blah/target/wtftw

If everything else fails, just do an

export RUST_LOG="debug"

on your shell before you do startx

[steveklabnik]

Ugh, now X crashes on startup rather than even loading wtftw :/

[Kintaro]

Huh, even with the export set and exec left as before?

[steveklabnik]

Yeah, something must be going on. Hmm...

[Kintaro]

Hm, I should run some tests on my old spare Thinkpad tomorrow.

[steveklabnik]

Okay, I have it all working now, and have turned on debug. Let's see if I can get the crash to happen.

[steveklabnik]

aaand three minutes till a crash.

https://gist.github.com/c6a3cc0708c4353fe5bb

there's the log

[Kintaro]

Hm, there are a few unmaps that seem to come out of nowhere. I may need to add more debug info tomorrow. I'll get this miserable bug, and if it's the last thing I ever do!

Thanks for finding this. Would've never catched that on my machine.

In the meantime: could you check if this is specific to Iceweasel or does it also happen randomly after a few minutes if anything but Iceweasel is running?

[steveklabnik]

When this crash happneed, I was actually screwing around in a desktop with only XTerms

[Kintaro]

Huh, so it threw you right back on the shell? Or was it the random doesn't-listen-to-key-commands bug?

[steveklabnik]

Randm doesn't-listen-to-keys

IIRC, I had no shells open, so I coudn't type anything. Had to just power cycle.

[Kintaro]

Should at least still listen so ctrl+alt+Fn to get you back on a tty. I really need to set that spare thinkpad up for testing.

[Kintaro]

Just as a little update: I'm going to work on some stability improvements over the weekend. Hopefully the issue will be resolved then. Otherwise I can only suspect that it's something that I'm missing in xlib.

[steveklabnik]

Cool, ping me and I'll try it again after the changes.

[Kintaro]

@steveklabnik Ping. There have been a few updates. Still not sure what exactly is causing your problems, but I'd love to know if the problem still persists.

[steveklabnik]

I'll give it a try soon.

[steveklabnik]

core fails to compile for me

src/util.rs:14:2: 14:3 error: expected item, found `;`
src/util.rs:14 );

[Kintaro]

Oh, you're running on a rustc version from last week I suppose. Macros now do have to end with semicolon.

[steveklabnik]

Ah! I thought I did it sooner than that. Lemme recompile

[Kintaro]

@steveklabnik And, still occuring or did the bug vanish?

[steveklabnik]

Okay, rebooting and trying 2b296e7ee1c1025564779aaa9cc5bd5fb4ac1a3a

[steveklabnik]

Soooo it just gives me a black screen, and i have to reboot.

[steveklabnik]

Nothing in my ~/.wtftw.log. I even rm'd ~/.wtftw and started, same deal :/

[Kintaro]

Ok, that definitely shouldn't happen. I figure if I get it to run stable on your system, then it'll be rock solid on all other systems out there :D

What distro are you using and which version of it?

[WildCryptoFox]

For reference: The closest thing I can get to a black screen on start is when the dynamic library imports structs with incompatible differences.

That crashes with the following:

1 XSELINUXs still allocated at reset
SCREEN: 0 objects of 160 bytes = 0 total bytes 0 private allocs
COLORMAP: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs
CLIENT: 0 objects of 56 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 72 bytes = 0 total bytes 0 private allocs
PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs
GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 24 bytes, 0 allocs
1 PIXMAPs still allocated at reset
PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs
GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 24 bytes, 0 allocs
1 DAMAGEs still allocated at reset
TOTAL: 0 objects, 0 bytes, 0 allocs

I am also very interested in why this isn't working. Are you trying to launch wtftw inside Xnest or Xephyr? If not, what do you get when you try from either?

Kintaro; as steveklabnik said in the original post here and in the topic: Debian Jessie.

[Kintaro]

m(

I should get some sleep before I post questions...

[Limvot]

Just wanted to mention that I am experiencing the same not-responding-to-keys behavior on Arch on my lenovo thinkpad with the most recent version of wtftw and rustc. It's really cool otherwise!

[steveklabnik]

Which thinkpad? I have a T440s.

[Kintaro]

Only instance when wtftw doesn't respond to keys anymore is when it crashes silently. Some xorg versions then revert back to your display manager or to tty. Some others remain active, so you can still see the open windows and interact with them, but wtftw is gone, so it can't react to shortcuts anymore.

Unfortunately I'm a bit busy with my thesis, but I'll try to stabilize it as much as I can as soon as possible.

[Limvot]

W540! Ah, gotcha. That makes sense. Thanks!

[Limvot]

I feel a little silly and apologize for possibly wasting your time: after running it through gdb I found that it was hanging on the "match p.write().unwrap().stdin.as_mut() {" line from my configuration (copied from the default configuration). After commenting it out, I've had no problems. Thanks!

[Kintaro]

Ah, so maybe you didn't have xmobar installed or something like that?

@steveklabnik what if you remove the bottom part of the config, the one about xmobar? Is it still happening then?

[steveklabnik]

I'll try it sometime, don't have time right now.

[Kintaro]

No hurry ^^ Busy myself.

[Limvot]

That's actually the odd part! I do have xmobar installed and it works fine, and I now just start it separately.

[FreeFull]

Also note keyboard shortcuts won't work while capslock is on, sometimes I accidentally press capslock and wonder why I can't switch workspaces anymore.

[coyotebush]

I also see it hanging on writing to xmobar after a few minutes, as confirmed through a few extra debug statements. Will see if I can figure out whether it's the RwLock or the Writer that gets stuck. (Debian Jessie, ThinkPad X220 here.)

[coyotebush]

So given these debug statements, the last thing in the log when it hangs is consistently "got stdin". Also, a few minutes before that happens, the StdinReader display in xmobar goes blank. Makes me think the pipe is getting clogged somehow, so to speak.

[FreeFull]

What does the xmobar config look like?

[coyotebush]

My xmobar config is also in that repository.

[steveklabnik]

So, trying this again, and when I start x, it just errors out. The only EE line in my log is

[ 42333.458] (EE) Server terminated successfully (0). Closing log file.

Sooooo unsure what's up with that. I have just this as my .xinitrc:

exec /home/steve/src/target/release/wtftw

Running it like in the readme works just fine.

[steveklabnik]

(and wtftw.log doesn't have anything, and i wiped my config)

[Kintaro]

I'll try to figure out what the problem is. As for the log file: since the log macro crate changed to being immutable I can't create and write to a log file anymore. Will have to write my own logging mechanisms for that.

[datagrok]

I'm seeing something similar but different in Debian testing (stretch). Upon launching wtftw under Xephyr and letting Xephyr grab the keyboard and mouse, some keybindings in wtftw seem to work fine (MOD1+Shift+Enter, MOD1+q, MOD1+Shift+q) but others don't (MOD1+h and MOD1+l in particular.)

Also, to make any debug logging output happen at all, I had to add the env_logger crate and call env_logger::init().unwrap(); in fn main(). Using rustc 1.7.0-nightly (4744472fe 2016-01-02), wtftw commit 00d3dac.