Possible win32 memory bug

I'm working through some recent mpl bugs in the tracker. Here's one that relates to a mis-matched pair of PyObject_New/PyMem_DEL calls in _subprocess.c. This file is a copy of a file included with Python 2.5, so it's really a bug we inherited from there.

https://sourceforge.net/tracker/index.php?func=detail&aid=1949978&group_id=80706&atid=560720

Read the Debian bug for more detailed info:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468977

It seems this bug was found using an automated tool and only represents a theoretical problem. The Debian folks also rightly don't care since matplotlib's _subprocess.c only gets built in Win32 with Python < 2.5.

Note, however, that Python 2.5.2 includes the patch in the bug report as well as two other memory-related fixes, so I thought I would just update to that. I went ahead and committed this to SVN (branch and trunk), since I'm reasonably confident in this code, but it would be great if a regular Windows user could test this out and close the bug.

Cheers,
Mike

···

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:

I'm working through some recent mpl bugs in the tracker. Here's one that relates to a mis-matched pair of PyObject_New/PyMem_DEL calls in _subprocess.c. This file is a copy of a file included with Python 2.5, so it's really a bug we inherited from there.

https://sourceforge.net/tracker/index.php?func=detail&aid=1949978&group_id=80706&atid=560720

Read the Debian bug for more detailed info:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468977

It seems this bug was found using an automated tool and only represents a theoretical problem. The Debian folks also rightly don't care since matplotlib's _subprocess.c only gets built in Win32 with Python < 2.5.

Mike,

subprocess is new in 2.4, so I assume we should build it only for Python < 2.4, correct? In that case, it can be removed entirely from the trunk, since we are requiring >= 2.4 there. Last week I put in the version-checking and removed the subprocess build from setupext.py, but I did not remove the _subprocess.c file itself--just in case the decision to require 2.4 was reconsidered.

Eric

···

Note, however, that Python 2.5.2 includes the patch in the bug report as well as two other memory-related fixes, so I thought I would just update to that. I went ahead and committed this to SVN (branch and trunk), since I'm reasonably confident in this code, but it would be great if a regular Windows user could test this out and close the bug.

Cheers,
Mike

Eric Firing wrote:

Michael Droettboom wrote:

I'm working through some recent mpl bugs in the tracker. Here's one that relates to a mis-matched pair of PyObject_New/PyMem_DEL calls in _subprocess.c. This file is a copy of a file included with Python 2.5, so it's really a bug we inherited from there.

https://sourceforge.net/tracker/index.php?func=detail&aid=1949978&group_id=80706&atid=560720

Read the Debian bug for more detailed info:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468977

It seems this bug was found using an automated tool and only represents a theoretical problem. The Debian folks also rightly don't care since matplotlib's _subprocess.c only gets built in Win32 with Python < 2.5.

Mike,

subprocess is new in 2.4, so I assume we should build it only for Python < 2.4, correct? In that case, it can be removed entirely from the trunk, since we are requiring >= 2.4 there. Last week I put in the version-checking and removed the subprocess build from setupext.py, but I did not remove the _subprocess.c file itself--just in case the decision to require 2.4 was reconsidered.

Sounds good. We can leave my update on the 0.91.x maintenance branch, however. I suspect its fine to do so.

Cheers,
Mike

···

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA