You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And what I found problematic is <Py~ as PyTypeInfo>::SIZE is std::mem::size_of::<ffi::PyObject> for all Py~ types, which is not true.
Actually, PyDictObject is defined as (roughly)
It's certainly suspicious that the SIZE is incorrectly defined. However, I can't see where SIZE is actually used for PyDict. The only use I find of ::SIZE is in type_object::initialize_type(), which I don't think ever gets called for native types.
Related to #220, #407
cc: @konstin @joar @davidhewitt
So as I said now I'm investigating safer layout than our current pyclass, which is constructed (roughly) by
And what I found problematic is
<Py~ as PyTypeInfo>::SIZE
isstd::mem::size_of::<ffi::PyObject>
for all Py~ types, which is not true.Actually, PyDictObject is defined as (roughly)
So it's size 64bit * 4 = 32bytes larger than PyObject.
Is it the cause of segfault?
The text was updated successfully, but these errors were encountered: