comparison Python/pythonrun.c @ 37229:6e1a899cac8e legacy-trunk

Years in the making. objimpl.h, pymem.h: Stop mapping PyMem_{Del, DEL} and PyMem_{Free, FREE} to PyObject_{Free, FREE} in a release build. They're aliases for the system free() now. _subprocess.c/sp_handle_dealloc(): Since the memory was originally obtained via PyObject_NEW, it must be released via PyObject_FREE (or _DEL). pythonrun.c, tokenizer.c, parsermodule.c: I lost count of the number of PyObject vs PyMem mismatches in these -- it's like the specific function called at each site was picked at random, sometimes even with memory obtained via PyMem getting released via PyObject. Changed most to use PyObject uniformly, since the blobs allocated are predictably small in most cases, and obmalloc is generally faster than system mallocs then. If extension modules in real life prove as sloppy as Python's front end, we'll have to revert the objimpl.h + pymem.h part of this patch. Note that no problems will show up in a debug build (all calls still go thru obmalloc then). Problems will show up only in a release build, most likely segfaults.
author Tim Peters <tim.peters@gmail.com>
date Sun, 26 Mar 2006 23:27:58 +0000
parents 4706b7a1256c
children 89142cadcfb9
comparison
equal deleted inserted replaced
37228:8f7c03acaddd 37229:6e1a899cac8e
1455 break; 1455 break;
1456 } 1456 }
1457 v = Py_BuildValue("(ziiz)", err->filename, 1457 v = Py_BuildValue("(ziiz)", err->filename,
1458 err->lineno, err->offset, err->text); 1458 err->lineno, err->offset, err->text);
1459 if (err->text != NULL) { 1459 if (err->text != NULL) {
1460 PyMem_DEL(err->text); 1460 PyObject_FREE(err->text);
1461 err->text = NULL; 1461 err->text = NULL;
1462 } 1462 }
1463 w = NULL; 1463 w = NULL;
1464 if (v != NULL) 1464 if (v != NULL)
1465 w = Py_BuildValue("(sO)", msg, v); 1465 w = Py_BuildValue("(sO)", msg, v);