Fix element ownership tracking with may_dangle - #594
Conversation
|
this and #596 won't make it to v1.16.1, but we can make a second patch later |
|
Cool, thanks for the heads up |
|
yeah I was looking at this the other day whilst doing some refactoring and it looked weird to me does I have an intuition it is not, though I can't tell for sure we are reading the references in order to run the destructors, so the reference must be valid and the element not dropped, which means that dropping the element before the smallvec drops leads to us reading a dangling reference (even if later we aren't double freeing) I haven't personally used |
alejandro-vaz
left a comment
There was a problem hiding this comment.
that phantomdata was exactly what @bolshoytoster removed on v2 if I remember correctly
|
I did not know about this behaviour. v2 should be fine though, since |
alejandro-vaz
left a comment
There was a problem hiding this comment.
yeah I was looking at this the other day whilst doing some refactoring and it looked weird to me
does
may_dangleeven make sense there?? is it correct??I have an intuition it is not, though I can't tell for sure
we are reading the references in order to run the destructors, so the reference must be valid and the element not dropped, which means that dropping the element before the smallvec drops leads to us reading a dangling reference (even if later we aren't double freeing)
I haven't personally used
may_dangleuntil now so I'm somewhat confused
alejandro-vaz
left a comment
There was a problem hiding this comment.
just researched how may_dangle actually works
it is correct now
thanks for contributing
With
may_dangleenabled, we currently allow references read by an element's destructor to expire before the vector is dropped, causing a use-after-free.Track ownership of
A::ItemwithPhantomDataso drop checking rejects this, including spilled vectors with zero inline capacity. Plain borrowed references without destructors retain the intendedmay_danglebehavior.