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
If the value set in the pointer_attribute is an object generated by Python/Boost.Python, the memory will eventually be double free if the memory is managed by the C++ side. This can be circumvented by the user, but this is incompatible with the actual Source.Python implementation. Furthermore, this means that when the user handles a pointer_attribute, it must be fully aware of how the memory is managed. While this may be feasible at the library level, it is impractical at the user level.
These two problems eventually lead to segmentation violation or double free or memory corruption, and these problems are very difficult or impossible to debug.
Proposal:
We should not assign the pointer of an object generated by Python/Boost.Python directly to other memory location, we should always make a copy of it and assign it, as in an earlier implementation (7690d96).
# A: Maybe it's a shared pointer which means that other
# classes might also have the address of it. So, changing
# address in this particular class wouldn't affect the
# other classes.
value.copy(ptr, self[attr_type].__size__)
This means that _allocated_pointers/_pointer_values are no longer required. If the user needs to delete a copied object, they can always use CustomType._destructor.
The text was updated successfully, but these errors were encountered:
The values given to pointer_attribute are managed by CustomType's _allocated_pointers/_pointer_values, but since CustomType may be generated from raw pointers, CustomType cannot have ownership of the value. This applies to CustomType generated by
make_object()
, nested CustomType, and Array generated by static_pointer_array/dynamic_pointer_array.(See also TypeManager.pointer_attribute cannot be safely used in nested CustomType. #480, TypeManager.static_pointer_array/TypeManager.dynamic_pointer_array are broken. #489).
If the value set in the pointer_attribute is an object generated by Python/Boost.Python, the memory will eventually be double free if the memory is managed by the C++ side. This can be circumvented by the user, but this is incompatible with the actual Source.Python implementation. Furthermore, this means that when the user handles a pointer_attribute, it must be fully aware of how the memory is managed. While this may be feasible at the library level, it is impractical at the user level.
These two problems eventually lead to segmentation violation or double free or memory corruption, and these problems are very difficult or impossible to debug.
Proposal:
We should not assign the pointer of an object generated by Python/Boost.Python directly to other memory location, we should always make a copy of it and assign it, as in an earlier implementation (7690d96).
Source.Python/addons/source-python/packages/source-python/memory/__init__.py
Lines 394 to 399 in 7690d96
This means that _allocated_pointers/_pointer_values are no longer required. If the user needs to delete a copied object, they can always use CustomType._destructor.
The text was updated successfully, but these errors were encountered: