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
Describe the bug
This is directly related to rapidsai/rmm#1156. I recently tried to add in some extra error checking on top of cudf::strings::concatenate because I wanted to be ready in case #12087 didn't work out. As a part of this I tested overflowing by just a very small amount 4 characters more than the maximum amount. To my shock the call to concatenate passed but trying to convert that result to a column_view threw an exception saying that a column_view cannot have a negative length. It appears that the negative allocation is turned into a very large positive allocation because C++ inserts in an implicit cast with no warnings, then rapidsai/rmm#1156 kicks in and causes the allocation to be converted to 0 which returns a nullptr and succeeds. My concern is not so much with strings directly. Even if #12087 is fixed the same kind of thing can happen for any allocation that overflows by a small amount.
Steps/Code to reproduce bug
Allocate a numeric_column of INT8 with a length of -4. It will work and there will be no exceptions until you try to turn it into a column_view, which might not happen if you are trying to use the column directly to pull out raw pointers/etc.
Expected behavior
I would like very much if it were not possible to allocate negative length columns. If we have the assertion on a column_view why do we not have the same thing for a column? This way even if the RMM issue is fixed don't have to wonder about why we are trying to allocate really large allocations from RMM that failed, but instead we can take the next step and know that something overflowed and we need to look at who is trying to allocate a negative column.
The text was updated successfully, but these errors were encountered:
Describe the bug
This is directly related to rapidsai/rmm#1156. I recently tried to add in some extra error checking on top of
cudf::strings::concatenate
because I wanted to be ready in case #12087 didn't work out. As a part of this I tested overflowing by just a very small amount 4 characters more than the maximum amount. To my shock the call to concatenate passed but trying to convert that result to acolumn_view
threw an exception saying that acolumn_view
cannot have a negative length. It appears that the negative allocation is turned into a very large positive allocation because C++ inserts in an implicit cast with no warnings, then rapidsai/rmm#1156 kicks in and causes the allocation to be converted to 0 which returns anullptr
and succeeds. My concern is not so much with strings directly. Even if #12087 is fixed the same kind of thing can happen for any allocation that overflows by a small amount.Steps/Code to reproduce bug
Allocate a
numeric_column
ofINT8
with a length of-4
. It will work and there will be no exceptions until you try to turn it into a column_view, which might not happen if you are trying to use the column directly to pull out raw pointers/etc.Expected behavior
I would like very much if it were not possible to allocate negative length columns. If we have the assertion on a
column_view
why do we not have the same thing for acolumn
? This way even if the RMM issue is fixed don't have to wonder about why we are trying to allocate really large allocations from RMM that failed, but instead we can take the next step and know that something overflowed and we need to look at who is trying to allocate a negativecolumn
.The text was updated successfully, but these errors were encountered: