python processes remain unkilled on OS X

65 views
Skip to first unread message

Manuel Ortega

unread,
Feb 9, 2016, 7:57:32 AM2/9/16
to vim...@googlegroups.com
On OS X 10.11.3, the 'make test' step runs tests of the new channel stuff.  By looking at Activity Monitor.app, this opens at least three processes called "python2.7".  At least one of them is quickly quit, but two remain running even after the 'make test' has completed running.

I first noticed this because there were about 15 or 20 such processes running.  I had built and tested Vim several times since my last login, and all those pythons were left up.

This is reproducible every time.

-Manny

Bram Moolenaar

unread,
Feb 9, 2016, 8:28:16 AM2/9/16
to Manuel Ortega, vim...@googlegroups.com
Can you try again after the change I just sent out? Patch 7.4.1294.

--
Some of the well known MS-Windows errors:
EHUH Unexpected error
EUSER User error, not our fault!
EGOD Horrible problem, god knows what has happened
EERR Errornous error: nothing wrong

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Olaf Dabrunz

unread,
Feb 9, 2016, 10:39:32 AM2/9/16
to vim...@googlegroups.com
On 09-Feb-16, Bram Moolenaar wrote:
>
> Manuel Ortega wrote:
>
> > On OS X 10.11.3, the 'make test' step runs tests of the new channel stuff.
> > By looking at Activity Monitor.app, this opens at least three processes
> > called "python2.7". At least one of them is quickly quit, but two remain
> > running even after the 'make test' has completed running.
> >
> > I first noticed this because there were about 15 or 20 such processes
> > running. I had built and tested Vim several times since my last login, and
> > all those pythons were left up.
> >
> > This is reproducible every time.
>
> Can you try again after the change I just sent out? Patch 7.4.1294.

It may also be necessary to start the server with "exec", so it uses the
process group of the shell.

--
Olaf Dabrunz (oda <at> fctrace.org)

Manuel Ortega

unread,
Feb 9, 2016, 11:36:05 AM2/9/16
to vim...@googlegroups.com
This *was* with 7.4.1294.  Sorry, I should've been clear about that.

On 09-Feb-16, Bram Moolenaar wrote:
> Can you try again after the change I just sent out?  Patch 7.4.1294.

This *was* with 7.4.1294.  Sorry, I should've been clear about that.

BTW, the number of leftover, unkilled python processes seems to be sometimes two, sometimes three.  Maybe that helps in some way.

-Manny 

Bram Moolenaar

unread,
Feb 9, 2016, 12:42:02 PM2/9/16
to Olaf Dabrunz, vim...@googlegroups.com

Olaf Dabrunz wrote:

> In-Reply-To: <2016020915...@santana.dyndns.org>
>
> On 09-Feb-16, Bram Moolenaar wrote:
> >
> > Manuel Ortega wrote:
> >
> > > On OS X 10.11.3, the 'make test' step runs tests of the new channel stuff.
> > > By looking at Activity Monitor.app, this opens at least three processes
> > > called "python2.7". At least one of them is quickly quit, but two remain
> > > running even after the 'make test' has completed running.
> > >
> > > I first noticed this because there were about 15 or 20 such processes
> > > running. I had built and tested Vim several times since my last login, and
> > > all those pythons were left up.
> > >
> > > This is reproducible every time.
> >
> > Can you try again after the change I just sent out? Patch 7.4.1294.
>
> It may also be necessary to start the server with "exec", so it uses the
> process group of the shell.

The command used is:
let s:job = job_start("python test_channel.py")

It's not using a shell, only starts the python process. Is that correct
Manuel, you only see one kind of process?

If it's not the way it's started, it could be that Python on Mac
behaves slightly differently. Exiting a multi-threaded process may hang
if some thread still runs.

I gave it a try, and indeed seems like the python processes just don't
exit. Killing the processes from the command line works, I wonder why
Vim isn't able to kill them, calling kill() would do the same thing.

--
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.

Manuel Ortega

unread,
Feb 9, 2016, 1:51:23 PM2/9/16
to vim...@googlegroups.com
On Tue, Feb 9, 2016 at 12:41 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

Olaf Dabrunz wrote:

> In-Reply-To: <2016020915...@santana.dyndns.org>
>
> On 09-Feb-16, Bram Moolenaar wrote:
> >
> > Manuel Ortega wrote:
> >
> > > On OS X 10.11.3, the 'make test' step runs tests of the new channel stuff.
> > > By looking at Activity Monitor.app, this opens at least three processes
> > > called "python2.7".  At least one of them is quickly quit, but two remain
> > > running even after the 'make test' has completed running.
> > >
> > > I first noticed this because there were about 15 or 20 such processes
> > > running.  I had built and tested Vim several times since my last login, and
> > > all those pythons were left up.
> > >
> > > This is reproducible every time.
> >
> > Can you try again after the change I just sent out?  Patch 7.4.1294.
>
> It may also be necessary to start the server with "exec", so it uses the
> process group of the shell.

The command used is:
    let s:job = job_start("python test_channel.py")

It's not using a shell, only starts the python process.  Is that correct
Manuel, you only see one kind of process?

I see only "python2.7" (two or three times).  There are no extra 'sh', 'bash', or 'vim' that shouldn't be there.

This is using the system's built-in python; I get the same result if I use a custom python.

-Manny

Ozaki Kiichi

unread,
Feb 9, 2016, 3:46:49 PM2/9/16
to vim_dev
I checked test_channel.vim on OS X 10.11.3;

ch_open('localhost' . s:port) fails by timeout, so s:start_server() returns (channel)-1 and s:kill_server() doesn't execute.

patch:
I propose to use try-finally to execute s:kill_server().
https://gist.github.com/ichizok/3820b16b7198847e75c7

And, on OS X, ch_open() needs option waittime > 0 to pass test_channel.

patch:
use waittime option
https://gist.github.com/ichizok/30ae71b0e12b85a1f864

Thank you.
- Ozaki Kiichi

Bram Moolenaar

unread,
Feb 9, 2016, 5:38:58 PM2/9/16
to Ozaki Kiichi, vim_dev
Thanks, I'm glad you could solve this mystery.

I do wonder why a 1 msec waittime makes it work, it probably means there
is something wrong with what happens with the zero waittime.

--
hundred-and-one symptoms of being an internet addict:
206. You religiously respond immediately to e-mail, while ignoring
your growing pile of snail mail.

Manuel Ortega

unread,
Feb 9, 2016, 10:22:17 PM2/9/16
to vim...@googlegroups.com
On Tue, Feb 9, 2016 at 5:38 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

Ozaki Kiichi wrote:

> I checked test_channel.vim on OS X 10.11.3;
>
> ch_open('localhost' . s:port) fails by timeout, so s:start_server()
> returns (channel)-1 and s:kill_server() doesn't execute.
>
> patch:
> I propose to use try-finally to execute s:kill_server().
> https://gist.github.com/ichizok/3820b16b7198847e75c7
>
> And, on OS X, ch_open() needs option waittime > 0 to pass test_channel.
>
> patch:
> use waittime option
> https://gist.github.com/ichizok/30ae71b0e12b85a1f864

Thanks, I'm glad you could solve this mystery.

I do wonder why a 1 msec waittime makes it work, it probably means there
is something wrong with what happens with the zero waittime.

I can confirm that 7.4.1297 has fixed the issue on my machine.  Thanks for the quick fix.

-Manny 
Reply all
Reply to author
Forward
0 new messages