Porting woes

Martin v. Löwis loewis at informatik.hu-berlin.de
Fri Sep 20 18:57:56 CEST 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