[Patches] Object leak in recursive comparison checker

Mark Hammond mhammond@skippinet.com.au
Fri, 9 Jun 2000 14:22:06 +1000


Im fairly confident there is a dictionary leak in the new
get_inprogress_dict() function in object.c

It is clear that this function returns a dictionary with _no_ reference
count added.  However, when it creates the dict, it returns an INCREF'd
dict.  Fortunately, we also stash the reference to this object in another
dict, so we can safely DECREF our created reference (well, at least as
safely as the other branch can return the existing dict with no new
reference)

The diff below is a 12 line context diff to help you see all relevant code.
If you look at the usage of this function, you can also see the result is
never DECREFd.

My object reference leak vanished, and the full test suite completes, after
making this change...

Mark.

diff -c -1 -2 -r2.70 object.c
*** object.c	2000/05/03 23:44:35	2.70
--- object.c	2000/06/09 04:16:02
***************
*** 342,365 ****
--- 342,367 ----
  	}
  	inprogress = PyDict_GetItem(tstate_dict, _PyCompareState_Key);
  	if (inprogress == NULL) {
  		PyErr_Clear();
  		inprogress = PyDict_New();
  		if (inprogress == NULL)
  			return NULL;
  		if (PyDict_SetItem(tstate_dict, _PyCompareState_Key,
  				   inprogress) == -1) {
  		    Py_DECREF(inprogress);
  		    return NULL;
  		}
+ 		/* The tstate_dict has a ref - we can now free ours */
+ 		Py_DECREF(inprogress);
  	}
  	return inprogress;
  }

  static PyObject *
  make_pair(v, w)
  	PyObject *v, *w;
  {
  	PyObject *pair;

  	pair = PyTuple_New(2);
  	if (pair == NULL) {




Release info:

I confirm that, to the best of my knowledge and belief, this contribution
is free of any claims of third parties under copyright, patent or other
rights or interests ("claims").  To the extent that I have any such claims,
I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide
license to reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part of the
Python software and its related documentation, or any derivative versions
thereof, at no cost to CNRI or its licensed users, and to authorize others
to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or not
to incorporate this contribution in the Python software and its related
documentation.  I further grant CNRI permission to use my name and other
identifying information provided to CNRI by me for use in connection with
the Python software and its related documentation.

Mark.