Modify

Opened 6 years ago

Closed 5 years ago

#3675 closed defect (fixed)

defunkt and open processes

Reported by: naxat88@… Owned by: hvr
Priority: normal Component: GitPlugin
Severity: normal Keywords:
Cc: matt@… Trac Release: 0.11

Description

Hello,

browsing the source-code/wiki/timeline/... with GitPlugin results in defunkt git processes and some other processes won't close properly after serving the request. After some time the operating system runs out of memory and it won't be possible to ssh into the server anymore :(.
Unfortunately I haven't found out how to reproduce the bug properly :(. ps aux | grep gi[t] prints the following processes:

www-data  3273  0.0  0.0   4948  1232 ?        S    15:31   0:00 git --git-dir=/pub/scm/snip-fu/ cat-file blob bca73b2b96c5f68566fc08547489dfdf8a6babbb
www-data  3562  0.2  0.0      0     0 ?        Z    15:35   0:00 [git] <defunct>

I'm using Trac 0.11, Python 2.5, git 1.5.6.3 on Debian Etch 4.0 with the latest svn-version of the plugin.
My config looks like:

[git]
cached_repository = true
persistend_cache = true

kind regards

Attachments (1)

gitplugin.fix.patch (1.6 KB) - added by matt@… 6 years ago.

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by matt@…

comment:1 follow-up: Changed 6 years ago by matt@…

I also encountered this problem, I've attached gitplugin.fix.patch above. This refactors the popen code to use the subprocess module and makes sure to wait() on the opened process to ensure that the process is closed.

As a footnote, I expect only people with persistent python interpreters (I was using mod_python) to suffer from this bug. The old popen code was very poorly thought out, it left persistent processes open because it relied on them being reaped when the parent interpreter died, this never happens in mod_python. Net result is that the git cat-file processes got left open and gradually filled all the ram in the machine.

comment:2 Changed 6 years ago by anonymous

  • Cc matt@… added

comment:3 in reply to: ↑ 1 Changed 6 years ago by anonymous

Replying to matt@sysctl.co.uk:

I also encountered this problem, I've attached gitplugin.fix.patch above. This refactors the popen code to use the subprocess module and makes sure to wait() on the opened process to ensure that the process is closed.

As a footnote, I expect only people with persistent python interpreters (I was using mod_python) to suffer from this bug. The old popen code was very poorly thought out, it left persistent processes open because it relied on them being reaped when the parent interpreter died, this never happens in mod_python. Net result is that the git cat-file processes got left open and gradually filled all the ram in the machine.

:-(

actually, the idea behind the current code was to rely on the garbage collector in order to avoid having to read all input at once synchronously, and instead be able to pass file descriptors to the upper layers, which could then decide to read only a part... I had lazy evaluation in mind when I coded this, and the hope to reduce the amount of in-memory buffers...

comment:4 Changed 6 years ago by matt@…

Granted it isn't an awful idea, it falls a bit flat on Linux though :(. The processes won't disappear until they've been waited on (to read the exit code), it looks as if nothing that gets given the popened process bothers doing this. Though this isn't your fault anyway, it still causes massive memory problems when it goes pear-shared in mod_python.

I've been using the modified GitPlugin on my server for a couple of days now, without any problems so far. Certainly hasn't left any processes lying around. While the lazy evaluation idea is nice, the net result was far from what you probably expected. Sounds like you're a prolog man ;)

comment:5 Changed 6 years ago by hvr

actually, I've got a bit of a Haskell fetish (not that I'd dislike Prolog...)

anyway, right now I starting to wonder whether tracd has the same issue, and also if there are other resource leaks with the combination mod_python+Trac lurking around...

comment:6 Changed 6 years ago by naxat88@…

I'm actually using tracd behind an apache proxy and it has this issue.

comment:7 Changed 6 years ago by mail@…

I can confirm this patch fixes this behaviour.
Thanks!

Running on Gentoo:

  • apache-2.2.9
  • mod_python-3.3.1
  • python-2.5.2
  • git-1.5.6.4
  • trac-0.11.2
  • track-hacks.org gitplugin from Nov. 21th, 2008

comment:8 Changed 6 years ago by bernat@…

I also have this bug using trac-git from Debian Lenny (2008/07/10 + some patches).

Is it any issue with the patch provided?

comment:9 Changed 6 years ago by thatch

IIRC close_fds=True is not supported on Windows.

comment:10 Changed 5 years ago by hvr

(In [5375]) GitPlugin: converted os.popen3() call to subprocess.Popen() and wait for process termination (addresses #3675)

comment:11 Changed 5 years ago by hvr

  • Resolution set to fixed
  • Status changed from new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.