Failed evals block forever

[kentfredric]

Similar but distinct from #276

cqc
(invalid code)

vim hangs

looking at the process table shows me

8944 /usr/lib/python-exec/python3.5/python /home/kent/clojure/vim-fireplace/python/nrepl_fireplace.py localhost 37609 /tmp/veC0Oww/12 call 228:d4:code110:[(symbol (str "\n\b" (apply str (interleave (repeat "\n") (map str (.getStackTrace *e)))) "\n\b\n")) *3 *2 *1]2:id31:fireplace-katipo2-1472843807-402:ns4:user2:op4:eval7:session36:528b2898-9228-4574-b9ce-2e3d4a9412ede l4:donee d2:id31:fireplace-katipo2-1472843807-40e

But straceing the failed process simply states:

select(4, [3], [], [], {0, 67719})      = 0 (Timeout)
stat("/tmp/veC0Oww/12", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/veC0Oww/12", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/veC0Oww/12", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/veC0Oww/12", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/veC0Oww/12", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/veC0Oww/12", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0

Ad infinitium.

nREPL server started on port 37609 on host 127.0.0.1 - nrepl://127.0.0.1:37609
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.8.0
OpenJDK 64-Bit Server VM 1.8.0_101-b13

[kentfredric]

And there's a lot of conditions that create this problem, omni-complete for instance does it as well. :/

[tpope]

Have you tried with a Vim version with if_pyth?

[kentfredric]

By that I assume you mean "with python support baked in". Not yet

[tpope]

Well, that's generally more reliable, if you want to give it a go.

[kentfredric]

After recompiling with python there was an initial issue where connected failed and strace died forever:

stat("/tmp/vfh5Vrn/13", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/vfh5Vrn/13", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)
stat("/tmp/vfh5Vrn/13", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
select(4, [3], [], [], {0, 100000})     = 0 (Timeout)

However, after killing the python thread and restarting the repl server the problem seems to have abated and eval appears to work a little better, but I still get periodic "hung" responses that need killing and I can't work out exactly what patterns are causing them. ( I had one happen during macro expand )

The only thing I can still see as the occurrence is it does fail hard when a failure occurs instead of reporting the failure. ( Because some of the things I input in a repl standalone which causes failures always cause the indefinate lockup ).

However, its not possible for me to know if errors are happening in every case from vim-fireplace, because the error itself (and whether or not there was an error) is concealed from me entirely and all I see in its stead is a lack of response.

[kentfredric]

Its weird.

• new vim session
• new repl session
• Connect
• HUNG
• process kill
• Connect
• OK

[alehatsman]

Seems like i have the same issue. If i am not wrong that is because of using python 3+

[delayedchoice]

I'm not sure it's the same issue, but i think there is definitely some mis-match between python/fireplace/java ... not sure what but its gotten real flaky in the last few days... trying to narrow it down ..

This is as close as i can get... not sure what it means...

chdir(/home/chronos/user/dev/clojure/test)
Error detected while processing function <SNR>108_RunTests[38]..fireplace#capture_test_run
[21]..<SNR>108_eval[2]..fireplace#client[2]..fireplace#platform[9]..fireplace#register_port_file[9]..fireplace#nrepl_connection#open
[13]..fireplace#nrepl#for[10]..<SNR>165_nrepl_process[1]..<SNR>165_nrepl_message[3]..<SNR>165_nrepl_call[3]..<SNR>164_nrepl_transpor
t_call[2]..<SNR>164_nrepl_transport_dispatch:
line    6:
E605: Exception not caught: nREPL: unexpected end of bencode data^@
Error detected while processing function <SNR>108_RunTests[38]..fireplace#capture_test_run[21]..<SNR>108_eval[2]..fireplace#client[2
]..fireplace#platform:
line    9:
E171: Missing :endif

Maybe python2 vs python3? I have only python 3.

[delayedchoice]

Python 2.7 does in fact fix for me.

[alehatsman]

i also moved to python 2.7 and it is fine now

[tpope]

Well that narrows it down. I do aim to support both major versions of Python, but I think someone else is going to have to step up to get the underlying problem fixed.

[bbatsov]

Pardon my ignorance, but how is python used exactly by fireplace? Does it shell out to a python nREPL client?

[tpope]

Vim can optionally optionally be dynamically linked to Python, enabling a crude interface for running Python directly inside of Vim. Fireplace uses this if it's available, and falls back to shelling out if not.

It's gotten untenably messy because in addition to having to deal with the integrated/shell dichotomy and the Python 2/3 dichotomy, we also have to deal with the fact some on some systems (notably Arch), the python shell command and :python Vim command call Python 3, while others use Python 2 for those and require you to call python3 and :python3 to get version 3.

Given that it's 2019, I'm strongly tempted to axe Python 2 support, but MacOS still doesn't ship with it, and I'm guessing that's the majority of the install base. Instead, I'm shipping a change to favor :python3 if it's available, as part of a more gradual phase out. With a small syntax tweak, it's working fine on my machine, so I'm hoping this particular issue is resolved.

[tvirolai]

For whatever reason, I started experiencing this issue since the latest update. Downgrading Fireplace to the previous version fixed it. I'm running Neovim on the latest OS X.

[awcot]

I'm using Neovim on Arch Linux, latest everything. Changing autoload/fireplace/nrepl_connection.vim to always use Python 2 instead of Python 3 seems to have resolved this issue for me.

[tpope]

Are you two experiencing hangs or an error? And is it using the internal Python interface or shelling out?

[tpope]

I've uncovered and fixed a string encoding issue on Python 3 that could have been the cause of this.

[tvirolai]

Unfortunately the problem persists on my system. I'm getting the hang when trying to evaluate invalid code such as

(defn foo [x]
  (println y))

I have to kill either the Java or Nvim process to get out of it. If I understand correctly, it's using the internal interface, at least both :has('python3') and :has('python') return 1.

This seems to be related to some change in commit 8ccbaf0cfde235126af3346705a4c2945b32cd77 (Favour Python3, Wed May 1 17:18:40 2019) since it seems to be the first version doing this.

[awcot]

The hanging persists after updating the plugin.

[tpope]

With that particular invalid code I can now reproduce the hang, albeit inconsistently. Let me see what I can do.

[tpope]

This was a doozy, but I think I've finally gotten to the bottom of it.