Vim hangs when closing debugger pressing <F6>

[dave2309]

Hi @BlackIkeEagle ,

Unfortunately I have a little issue, I did not really notice before (saying I don't know if it is knew).
When going using the debugger and the pressing vim just hangs.
I don't recall such issue for long time.
Log file does not output anything.
I have a minimal vimrc file with just vdebug (to avoid conflicts with some other plugins)

Where/How can I found something relevant?

Regards,
Dave

[terminator-ivanovich]

I have the same problem

[dave2309]

I have the same problem

I use Ubuntu 20.04, vim 8.2
Since when does it stop working for you?

[terminator-ivanovich]

It begins after last commit by @BlackIkeEagle
15b6910

It's seems that vdebug only one php debugger for vim. Vim is a great code editor and it will be very best to make php debugger for vim. Vdebug is a good debugger, but have a lot off bugs. Unfortunately I don't know phyton. And I have to learn phyton for finish vdebug.

[lucc]

If someone knows ruby and can make sense of the ruby tests that would also help :)

[dave2309]

@BlackIkeEagle it seems that commenting out line 188 in python3/vdebug/connection.py
make things working again.
s.settimout(5)
@terminator-ivanovich @lucc can you confirm?

[BlackIkeEagle]

@dave2309 is this with break_on_open: 1 or 0 ?

[BlackIkeEagle]

@dave2309 and @terminator-ivanovich could you post the relevant vdebug config you are using

I can't reproduce this, F6 always lets me close just fine

[terminator-ivanovich]

Arch5.4.69 (linux-lts), python3.8.5, php7.4.10, xdebug2.9.6, vim8.2.17(installed by gvim8.2.17)
from .vimrc :

if !exists('g:vdebug_options')
    let g:vdebug_options = {}
endif
let g:vdebug_options.break_on_open = 0
let g:vdebug_options.ide_key = 'VIM'
let g:vdebug_options.watch_window_style = 'compact'
let g:vdebug_options.port = 9000

let g:vdebug_keymap = {
    \    "run" : `"<F5>",`
    \    "run_to_cursor" : "<F9>",
    \    "step_over" : "<F2>",
    \    "step_into" : "<F3>",
    \    "step_out" : "<F4>",
    \    "close" : "<F6>",
    \    "detach" : "<F7>",
    \    "set_breakpoint" : "<F8>",
    \    "get_context" : "<F11>",
    \    "eval_under_cursor" : "<F12>",
    \    "eval_visual" : "<Leader>e",
    \}

I took this keymap from vdebug help pages. I made only this configs with vdebug. I have no any vdebug configs.

[terminator-ivanovich]

@BlackIkeEagle it seems that commenting out line 188 in python3/vdebug/connection.py
make things working again.
s.settimout(5)
@terminator-ivanovich @lucc can you confirm?

This action return very big mistake in my system.

[dave2309]

@dave2309 is this with break_on_open: 1 or 0 ?

if !exists('g:vdebug_options')
    let g:vdebug_options = {}
endif
let g:vdebug_options.break_on_open = 0
let g:vdebug_options.watch_window_style = 'compact'

[BlackIkeEagle]

@terminator-ivanovich and @dave2309 the watch_window_style = 'compact' seems to be the issue, I'll look into it further

[dave2309]

@BlackIkeEagle steps that I reproduce with FF and brave.

1. put a breakpoint
2. start F5
3. browser to url
4. on breakpoint stop, just continue F5
5. vdebug says session finishes (until here all normal)
6. F6 -> vim hangs with message "debugger.close()"
7. refresh browser same url
8. back in vim no longer hangs, can F6 that stop debugger

It seems that instead of closing, it does "restart" waiting for connection, then playing an extra URL does free it.

The issue does not happen if continuous_mode=0 (but I need it due to some pages with a few xhr calls)

Commenting out line 188 make things working for me

[dave2309]

@BlackIkeEagle

@terminator-ivanovich and @dave2309 the watch_window_style = 'compact' seems to be the issue, I'll look into it further

Not for me, changing watch_window_style back to expanded does not change the issue... :(

[BlackIkeEagle]

Just noticed, I had it with your settings, and not if I just add it to my original configuration

[dave2309]

@BlackIkeEagle can you show your configuration?

[BlackIkeEagle]

@dave2309
This: https://github.com/BlackIkeEagle/vimfiles/blob/master/vimrc-developer#L297-L307 is my default setup

[dave2309]

@BlackIkeEagle tried with you default configuration, issue still occurs.
Again commenting out line 188 does work.

[BlackIkeEagle]

@dave2309 if you PR it I'll take it, since this is consistently the solution for you, else I'm updating it this evening.

[dave2309]

@BlackIkeEagle PR done, can you check it?

[BlackIkeEagle]

@dave2309 thanks for putting in the effort

Will close this one since I think it will be solved

[meldafert]

This issue and #484 were introduced by me in #479, sorry.
I thought that the socket returned by accept() also inherited the timeout, not just the blocking mode, which is why I set a timeout on the client socket in the first place.
This turned out to be wrong, and I eliminated the need for a timeout on the listening socket in my PR, so the current code of not having a timeout anywhere should be correct.