01-12-2023, 08:57 AM
(This post was last modified: 01-12-2023, 09:12 AM by josemendez.)
(01-12-2023, 08:38 AM)kaser Wrote: Thanks response.
There is a section I would like to add regarding the issue of memory leak that was just mentioned
In the base Class of the original abstract type, there are two materialized implementations.
The object inheriting this Class is being implemented, and it seems that not two implementation types are being used.
Some concrete implementations of ObiNativeList<T> override/hide the parameterless constructor, as it's not supposed to do anything even when called by Unity. These are lists of data types that get serialized as part of assets (mainly, actor blueprints).
(01-12-2023, 08:38 AM)kaser Wrote: Therefore, when using isCreated as a judgment, such as the Int type List in the image below, there may be memory leaks due to incorrect implementation of ChangeCapacity, resulting in isCreated not being judged as true.The above is my current interpretation. If there are any inaccuracies, please let me know
Is it possible for the above issues to exist in the Obi system Flow?
I'm not sure I understand your explanation, ChangeCapacity is not only called by the list's constructor. It is also called when adding individual elements or a range of elements to the list, basically in any situation that we need to actually store something in the list.
As a result, even if the constructor is not called isCreated will be set true as soon as the list is used for the first time. As far as I can tell, there's no situation in which isCreated can be be false and the safety handle be valid simultaneously, leading to a leak (as a side note, AtomicSafetyHandle is a struct so it can't be leaked. They only exist to perform checks on other object's lifetimes).
However if the constructor is not called (and the safety handle is hence invalid) and the list is never used (so no ChangeCapacity calls either) and Dispose is called, it will attempt to destroy a handle that doesn't exist.
While this may seem reasonable from a user's perspective (raising an exception when attempting to destroy a list that hasn't had all of its data initialized), Unity's serialization system uses the list in this way. Making the safety handle destruction code depend on isCreated is correct as it will only attempt to destroy the safety handle if the list is properly initialized, as opposed to trying and throwing an exception as a result.
kind regards