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
The XGBoost API contains several APIs where memory management is internally handled and callers are assumed to ignore the lifetime concern. For example, consider the possible projection of the XGDMatrixGetFloatInfo API.
The above API suffers from two deficiencies. The first is the returned length is a ulong (64-bit), but Span<T> only supports lengths of int, the other is the returned pointer will be copied into managed memory by source generated and the unmanaged pointer freed by the Span<T> marshaller. The semantics of the C API dictate the unmanaged memory shouldn't be freed, so when it is heap corruption will ensue.
We should consider a mechanism for indicating returned unmanaged memory isn't to be freed. Note this particular API would still be broken due to the int vs ulong length conflict.
Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.
Issue Details
The XGBoost API contains several APIs where memory management is internally handled and callers are assumed to ignore the lifetime concern. For example, consider the possible projection of the XGDMatrixGetFloatInfo API.
The above API suffers from two deficiencies. The first is the returned length is a ulong (64-bit), but Span<T> only supports lengths of int, the other is the returned pointer will be copied into managed memory by source generated and the unmanaged pointer freed by the Span<T> marshaller. The semantics of the C API dictate the unmanaged memory shouldn't be freed so when it is heap corruption will ensue.
We should consider a mechanism for indicating returned unmanaged memory isn't to be freed. Note this particular API would still be broken due to the int vs ulong length conflict.
The XGBoost API contains several APIs where memory management is internally handled and callers are assumed to ignore the lifetime concern. For example, consider the possible projection of the
XGDMatrixGetFloatInfo
API.The above API suffers from two deficiencies. The first is the returned length is a
ulong
(64-bit), butSpan<T>
only supports lengths ofint
, the other is the returned pointer will be copied into managed memory by source generated and the unmanaged pointer freed by theSpan<T>
marshaller. The semantics of the C API dictate the unmanaged memory shouldn't be freed, so when it is heap corruption will ensue.We should consider a mechanism for indicating returned unmanaged memory isn't to be freed. Note this particular API would still be broken due to the
int
vsulong
length conflict.Related: #76974
The text was updated successfully, but these errors were encountered: