FWIW at this point i'm not willing to "fix" issues in Python 2.7's subprocess module for POSIX platforms as subprocess32 is a superior drop in alternative without the issues.

inspecting the 2.7 code, if you are seeing a memory leak and the statements that fail before the gc.enable call are more than "self._child_created = True" and "if self.pid == 0:", it must be the child process.

there DOES appear to be a unlikely but potential bug in the 2.7 child process code: its "os._exit(255)" call should really be within a finally: so that any exception raised during the bare "except:" phase somehow still exits.  that should be rare.  the result if missing that would be a runaway forked child process that does indeed have gc disabled but is in the process of propagating an exception upwards (and is likely to hit others along the way in the other finally: clauses) so it is would die anyways unless the calling code catches and dismisses that (possible).

so what I _imagine_ you _might_ be seeing somehow is the pre-exec forked child exception handling+reporting code failing and leading to a runaway child who's exception you caught and let keep running.  if you have this situation, something else odd is going on (is the os.write() failing?).

i've attached a _possible_ patch.  but i'd rather not commit this without a test that reproduces the situation (that sounds difficult).

I strongly recommend you just use subprocess32.