Thanks to visit codestin.com
Credit goes to github.com

Skip to content

job_stop cannot kill process tree on windows. #1184

@skywind3000

Description

@skywind3000

Version:
GVim - 8.0.45 32 bits on Win7 x64

Reproduce:

  1. Start a batch file by myjob = job_start(['cmd.exe', '/C', 'abc.cmd'], ...)
  2. Start a long-time-running command in the batch file.
  3. Stop job by call job_stop(myjob, 'kill')

Expect:
All the child processes should be killed according to the document.

Result:
Only cmd.exe gets killed, all child processes are still running, close_cb and exit_cb are not invoked.

Channel log:

==== start log session ====
  9.211493 : Starting job: C:\Windows\system32\cmd.exe /c C:\Users\Linwei\AppData\Local\Temp\asyncrun.cmd
  9.211862 on 0: Created channel
  9.276309 : looking for messages on channels
  9.377826 RECV on 0: 'Entering dir 'e:/lab/trunk'

python timer 0

'
  9.377837 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
  9.377921 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
  9.393713 : looking for messages on channels
 10.428161 RECV on 0: 'python timer 1

'
 10.428197 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
 10.470649 : looking for messages on channels
 11.432531 RECV on 0: 'python timer 2

(call job_stop, and cmd.exe exit here)

'
 11.432569 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
 11.437469 : looking for messages on channels
 12.220074 on 0: Stopping job with 'kill'
 12.239247 : looking for messages on channels
 12.239365 on 0: Job ended
 12.283459 : looking for messages on channels
 12.409692 RECV on 0: 'python timer 3

(but child process started by cmd.exe is still running) 

'
 12.409729 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
 12.429221 : looking for messages on channels
 13.401916 RECV on 0: 'python timer 4

.............

'
 17.432877 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
 17.453741 : looking for messages on channels
 18.366814 RECV on 0: 'python timer 9

'
 19.374784 on 0: Invoking channel callback <SNR>83_AsyncRun_Job_OnCallback
 19.376939 : looking for messages on channels
 19.390777 ERR on 0: channel_handle_events(): Read error from ch_part[1], closing
 19.390886 : looking for messages on channels
 19.390914 on 0: Closing channel because all readable fds are closed
 19.390935 on 0: Closing channel
 19.390969 on 0: Invoking callbacks before closing
 19.390991 on 0: Invoking close callback <SNR>83_AsyncRun_Job_OnClose
 19.391923 on 0: Freeing job
 19.443185 on 0: Closing channel
 19.443211 on 0: Clearing channel
 19.443219 on 0: Freeing channel
 19.443272 : looking for messages on channels

content of asyncrun.cmd:

@echo off
python timer.py

content of timer.py:

import time, sys
print 'Entering dir \'e:/lab/trunk\''
for i in xrange(10):
    print 'python timer', i
    sys.stdout.flush()
    time.sleep(1)
print 'Leaving dir'

Escaping and passing arguments correctly on windows are complex. Most plugins I see, including taglist/tagbar, will use a temporary batch to run commands on windows. In this case, the real job can never be killed if job_stop can only stop cmd.exe.

Most jobs have more than one process (eg, a building job, piped commands). If I start a complex grep like program on the root of my filesystem by mistake, which will be running for a long time, I can never stop them on windows ?

If I start a group of processes with the wrong parameters (like tail -f, findstr abc), which continues waiting data from stdin, but in_io is unset, they will never get stopped in vim ?

Most piped commands (dir | grep DIR) require cmd.exe to interprete the command line on windows, will they also unable to be killed by job_stop ?

If a lot of jobs hang in vim, and continue occupying the job slot, we will never able to start a new job until we exit vim and reenter again ?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions