Porting woes
Martin v. Löwis
loewis at informatik.hu-berlin.de
Fri Sep 20 12:57:56 EDT 2002
jstavnitzky at atsautomation.com (Jay) writes:
> This failure is occuring during the function classic_mro(). The
> stack at that point is
> classic_mro(),mro_implementation(),mro_internal(),PyType_Ready(),
> PyTypeReady(),Py_ReadyTypes(),Py_Initialize(),Py_Main().
>
> Help!! What is happening at this point, and what could be causing this
> assertion to fail?
It checks whether the cls argument to classic_mro really is a classic
class. It is surprising that it calls into classic_mro. Can you tell
which line in Py_ReadyTypes comes from? (type, list, string, ...?)
None of these are classic classes, so this code should not have been
executed. It appears that this was executed because of the test in
if (PyType_Check(base))
parentMRO = PySequence_List(
((PyTypeObject*)base)->tp_mro);
else
parentMRO = classic_mro(base);
i.e. base appears not to be a type. This, again, should not happen:
base is
PyObject *base = PyTuple_GET_ITEM(bases, i);
which in turn comes from
bases = type->tp_bases;
All base types of the types initialized in Py_ReadyTypes have only
types as bases, so it is surprising that one of them has a base which
is not a type.
It would be good to study the value of type, and tp_bases, at this
point. It might be that some initialization of global objects has
failed to happen, or has happened incorrectly.
Regards,
Martin
More information about the Python-list
mailing list