Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Travis E. Oliphant wrote: > I'm curious about the difference between > > float_subtype_new in floatobject.c > complex_subtype_from_c_complex in complexobject.c > > The former uses type->tp_alloc(type, 0) to create memory for the object > while the latter uses PyType_GenericAlloc(type, 0) to create memory for > the sub-type (thereby by-passing the sub-type's own memory allocator). > > It seems like this is a bug. Shouldn't type->tp_alloc(type, 0) also be > used in the case of allocating complex subtypes? I submitted an entry and a patch for this on SourceForge Tracker (#1498638) http://sourceforge.net/tracker/index.php?func=detail&aid=1498638&group_id=5470&atid=105470 -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Guido van Rossum wrote: I wouldn't be surprised if this is a genuine bug; the complex type doesn't get a lot of love from core developers. Could you come up with a proposed fix, and a unit test showing that it works (and that the old version doesn't)? (Maybe a good unit test would require writing a custome C extension; in that case just show some sample code.) Attached is a sample module that exposes the problem. The problem goes away by replacing op = PyType_GenericAlloc(type, 0); with op = type->tp_alloc(type, 0); in the function complex_subtype_from_c_complex in the file complexobject.c (about line #191). The problem with a unit test is that it might not fail. On my Linux system, it doesn't complain about the problem unless I first use strict pointer checking with export MALLOC_CHECK_=2 Then the code import bugtest a = bugtest.newcomplex(3.0) del a Aborts Valgrind also shows the error when running the simple code. It seems pretty clear to me that the subtype code should be calling the sub-types tp_alloc code instead of the generic one. Best regards, -Travis #include "Python.h" typedef struct { PyObject_HEAD double real; double imag; } PyNewComplexObject; static PyTypeObject PyComplex_SubType = { PyObject_HEAD_INIT(NULL) 0, /*ob_size*/ "newcomplex", /*tp_name*/ sizeof(PyNewComplexObject),/*tp_basicsize*/ }; static PyObject * _complex_alloc(PyTypeObject *type, int nitems) { PyObject *obj; obj = (PyObject *)malloc(_PyObject_SIZE(type)); memset(obj, 0, _PyObject_SIZE(type)); PyObject_INIT(obj, type); return obj; } PyMODINIT_FUNC initbugtest(void) { PyObject *m, *d; m = Py_InitModule("bugtest", NULL); d = PyModule_GetDict(m); PyComplex_SubType.tp_free = free; PyComplex_SubType.tp_alloc = _complex_alloc; PyComplex_SubType.tp_base = &PyComplex_Type; PyComplex_SubType.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES; PyType_Ready(&PyComplex_SubType); Py_INCREF(&PyComplex_SubType); PyDict_SetItemString(d, "newcomplex", (PyObject *)&PyComplex_SubType); return; } ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Guido> (Maybe a good unit test would require writing a custome C Guido> extension; in that case just show some sample code.) Isn't that what Module/_testcapimodule.c is for? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
I wouldn't be surprised if this is a genuine bug; the complex type doesn't get a lot of love from core developers. Could you come up with a proposed fix, and a unit test showing that it works (and that the old version doesn't)? (Maybe a good unit test would require writing a custome C extension; in that case just show some sample code.) --Guido On 5/31/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > > I'm curious about the difference between > > float_subtype_new in floatobject.c > complex_subtype_from_c_complex in complexobject.c > > The former uses type->tp_alloc(type, 0) to create memory for the object > while the latter uses PyType_GenericAlloc(type, 0) to create memory for > the sub-type (thereby by-passing the sub-type's own memory allocator). > > It seems like this is a bug. Shouldn't type->tp_alloc(type, 0) also be > used in the case of allocating complex subtypes? > > This is causing problems in NumPy because we have a complex type that is > a sub-type of the Python complex scalar. It sometimes uses the > complex_new code to generate instances (so that the __new__ interface is > the same), but because complex_subtype_from_c_complex is using > PyType_GenericAlloc this is causing errors. > > I can work around this by not calling the __new__ method for the base > type but this is not consistent. > > > Thanks for any feedback, > > -Travis > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type->tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type->tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, P.S. Sorry about the cross-posting to another thread. I must have hit reply instead of compose. Please forgive the noise. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type->tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type->tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com