| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Debug.Assert(type != IntPtr.Zero); | ||
| int typeSize = Marshal.ReadInt32(type, TypeOffset.tp_basicsize); | ||
| Debug.Assert(typeSize > 0 && typeSize <= ExceptionOffset.Size()); | ||
| Debug.Assert(typeSize > 0); |
Sorry, something went wrong.
There was a problem hiding this comment.
IMHO, the assert should stay. This PR does not address it, but probably solves the problem @koubaa has.
Sorry, something went wrong.
There was a problem hiding this comment.
The checking of typeSize <= ExceptionOffset.Size() is totally a wrong idea, there's no connection between them. Why an other object size whould relates to an exception object size.
You can simply make it lager than that size by
class A(B, C, D, E, F, G): pass
Sorry, something went wrong.
There was a problem hiding this comment.
@amos402 if I remember correctly, BaseOffset is only used for reflections of .NET classes created by Python.NET. Right now there are only two kinds of them: System.Exception and everything derived from it, that end up deriving Python's builtins.BaseException or builtins.Exception, and every other .NET type, which end up deriving from builtins.object. Within those two categories each of the types has identical structure, and the ones derived from Exception just happen to be larger.
When Python class is inherited from a reflected .NET class via single inheritance, and has no extra low-level PyType stuff defined explicitly, I see no reason for its objects to be larger, than corresponding base class objects. Hence all such types should have either the same size as reflected System.Object or as reflected System.Exception.
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
@koubaa I am fine with this PR without the check removal.
Sorry, something went wrong.
Codecov Report
@@ Coverage Diff @@
## master #1219 +/- ##
=======================================
Coverage 86.25% 86.25%
=======================================
Files 1 1
Lines 291 291
=======================================
Hits 251 251
Misses 40 40
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
Sorry, something went wrong.
|
@amos402 @koubaa the fix is still incomplete. It places GCHandle past the last field of PyType (or Python class type), it never allocates space for it, hence it still writes to an offset it does not own. For example, on Windows x64 Python 3.8 an instance of PyType is 880 bytes long. An instance of CLR Metatype, the type of all reflected classes, is also 880 bytes long. After this fix class Sub(System.Exception) invokes MetaType.tp_new, that has this line: pythonnet/src/runtime/metatype.cs Line 122 in 022be19 Where it writes the GCHandle immediately past the last byte of the new type object (an instance of CLR Metatype), because TypeOffset.members is also 880. To fix this it might be sufficient to increase tp_basicsize of CLR Metatype by IntPtr.Size to allocate space for GCHandle. |
Sorry, something went wrong.
|
It allocated the space, you can check PyType_GenericAlloc. It has an extra space sizeof(PyMemberDef), as long you only use the first pointer which is points to the name and not to use wearef to CLR types, it's fine. If you want to use more space roughly, you should skip the memory of type, because the typeobject may check it. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #1218
Changes taken from @amos402 soft shutdown branch