Kakoune hangs when running any easymotion command

[TeddyDD]

Kakoune v2018.10.27 Python 3.6.7 Shell: dash-0.5.10

Commit that breaks it for me: 9098e0ff15089e1a0b0ea469441d6f58d76d40cf

When running any easymotion command kakoune hangs and waits for some command to complete. I have to use <c-c> to stop the command. After this there's plenty of selections in the buffer, empty *pydef* buffer and some errors in debug

*** This is the debug buffer, where debug info will be written ***
Config-change detected:
Config-change detected:
error running hook ModeChange(insert:next-key)/: 2:6: 'set-option' no window in context
error running hook ModeChange(insert:normal)/: 2:6: 'set-option' no window in context

[Jackojc]

Having the same issue.

[aldanor]

@danr Any ideas?..

[greenfork]

Ping

[TeddyDD]

btw: if you are affected by this bug - 40d73d commit works fine for me, even on master branch.

[QuinnFreedman]

I'm having the same problem (in 7f080c172b9e0e20bf3866b9bc98cbc1d5c2d1cc) and can confirm that it works fine in 40d73d70904a7db3edaa3169212aa2f587d48e13

[danr]

Hmm... I don't see what's going on. Without 7f080c1 (using 40d73d7) we have \n literally being sent to kakoune. Can you check what set window debug commands gives you?

[danr]

I got rid of the scratch buffer and started using echo -to-file instead, maybe this will fix the problem. Can anyone check?

[gibfahn]

If I run easymotion-word, I get this:

With 40d73d7:

Screenshot


With current master (a0ee34a):

Screenshot


[danr]

Yes, you will need https://github.com/mawww/kakoune/commit/744778be. There will be a new kakoune release with this included shortly.

[TeddyDD]

With https://github.com/mawww/kakoune/commit/e4d6bff5ec1a6bf3a3456e26d51e53d85c282ea0 and https://github.com/danr/kakoune-easymotion/commit/a0ee34ac7f7b50f5fefdab0c3327d21edc64deae running any easymotion command hangs Kakoune definitely, I can't do anything, I have to kill process.

Ubuntu 19.04, Python 3.7.3 and 2.7.16

[danr]

Hmm I cannot reproduce this here. I'm using arch. The communication is via fifos, maybe the OS can buffer the fifos in different ways. I'm assuming line buffering.

[TeddyDD]

Hard to tell, I have this issue on Void as well.

[danr]

Are you testing with kak -n?

[TeddyDD]

I tried with -n and without it, no difference :(

[danr]

Can you try now? I pushed 9f69176.

Also https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe might be relevant...

[TeddyDD]

Still nothing. I tried stdbuf -oL -eL kak -n as well but it does not help (not sure if I use it correctly)

[danr]

Maybe try stdbuf -oL -iL cat $kakfifo here:

https://github.com/danr/kakoune-easymotion/blob/master/easymotion.kak#L22

Also can you try set window debug shell|commands in the window where you will run the easymotion command + have the debug buffer open? That way we might see how far we get before kakoune hangs.

[TeddyDD]

Also can you try set window debug shell|commands in the window where you will run the easymotion command + have the debug buffer open? That way we might see how far we get before kakoune hangs.

It would be good idea but debug buffer is not updated after I call any easymotion-command.

Maybe try stdbuf -oL -iL cat $kakfifo here:

Unfortunately it doesn't help

Strace (strace -o out.log kak -n -e 'source easymotion.kak; easy-motion-j') log: out.log

[danr]

I ran this too, while yours has this line:

openat(AT_FDCWD, "/tmp/tmp.Qv0LWFVlWH.py.pyfifo", O_WRONLY|O_CREAT|O_TRUNC, 0644) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=11484, si_uid=1000} ---

mine succeds with actually writing the parameters (the alphabet is em_jumpchars and so on), and later gets the reply starting with a select:

openat(AT_FDCWD, "/tmp/tmp.9GBM1vDndo.py.pyfifo", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 5
write(5, "abcdefghijklmnopqrstuvwxyz^1^e^^"..., 50) = 50
close(5)                                = 0
pipe([5, 6])                            = 0
pipe([7, 8])                            = 0
vfork()                                 = 17730
close(6)                                = 0
close(8)                                = 0
fcntl(-1, F_GETFL)                      = -1 EBADF (Bad file descriptor)
fcntl(-1, F_SETFL, O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_NONBLOCK|O_SYNC|O_DIRECT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|O_PATH|O_TMPFILE|FASYNC|0xff80003c) = -1 EBADF (Bad file descriptor)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
wait4(17730, 0x7ffe652ded94, WNOHANG, NULL) = 0
pselect6(8, [0 3 5 7], [], [], {tv_sec=0, tv_nsec=27970828}, {[], 8}) = 1 (in [5], left {tv_sec=0, tv_nsec=24842887})
select(6, [5], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [5], left {tv_sec=0, tv_usec=0})
read(5, "select 1.1,1.1\neasy-motion-rmhl\n"..., 1024) = 1024
select(6, [5], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [5], left {tv_sec=0, tv_usec=0})
read(5, " em_fg 1;_on_key '';easy-motion-"..., 1024) = 565
select(6, [5], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [5], left {tv_sec=0, tv_usec=0})
read(5, "", 1024)                       = 0

I don't know what to make out of this though. I'll ask Screwtape.

[Screwtapello]

To be restarted if SA_RESTART is set

SIGTERM

Just from that strace snippet, it looks like your attempt to openat() the FIFO just hangs until the Kakoune script (or something else) sends it SIGTERM. On my machine, fifo(7) says:

The FIFO must be opened on both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also.

...so I'd guess that's what's happening here. Could there be some kind of race condition where the reader tries to open the FIFO, fails, and exits before the writer tries to open it?

[meydjer]

When running any easymotion command kakoune hangs and waits for some command to complete. I have to use to stop the command. After this there's plenty of selections in the buffer, empty pydef buffer and some errors in debug

Same thing here on macOS

[danr]

The PR #18 was merged, does this help the hangs?

[TeddyDD]

It seems it helped, at least at my Void Linux machine. I'll check tomorrow on Ubuntu.

---

I tried on two other machines (Ubuntu and Mint) and it works.

[MrOneTwo]

Had the same problem (Void Linux). For me it was a python alias missing. I've solved it by making a symbolic link in the /bin directory:

cd /bin
sudo ln -s python3 python

Might be useful for others encountering this problem.

[aThorp96]

This issue has been stale for a while, but still happens by default on MacOS. It looks like switching the python command from python to python3 does the trick in my environment. Would you have any objection to this change @danr?