type_new() allocates the exact number of slots it's going to use, but
various other functions assume there's one more slot with a NULL name
field serving as a sentinel. I'm unsure why it doesn't normally crash.

Can you be more specific as to on which line number the questionable
allocation happens, and which functions are depending on there being one
extra slot?

typeobject.c:1842:type_new
type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots);
nslots may be 0.

typeobject.c:1966:type_new assigns this just-past-the-end address to
tp_members
type->tp_members = PyHeapType_GET_MEMBERS(et);

type_new later calls PyType_Ready, which calls add_members.
typeobject.c:3062:add_members
	for (; memb->name != NULL; memb++) {

Interestingly, traverse_slots and clear_slots both use Py_Size rather
than name != NULL (so I was wrong about the extent of the problem.)
Both seem only to be used for heap types. add_members is used by both
heap types and static C types, so it needs to handle both behaviours.

One possible (if ugly) solution would be to switch iteration methods
depending on if Py_Size() is 0 or not, making sure type_new sets
tp_members to NULL if Py_Size() is 0.

Are you sure you're not missing the +1 on line 440 in PyType_GenericAlloc()?

Ugh, you're right.

I refactored PyType_GenericAlloc out of my fork, which is why I got a crash.

Sorry for wasting your time.