why does value allocated in stack didn't result in double free pointer?

user_7607923 0
Viewed 122

Please tell me why didn't result in double free pointer that the value is allocated in stack? Thanks.

#[test]
fn read_value_that_allocated_in_stack_is_no_problem() {
    let origin = Value(1);
    let copied = unsafe { std::ptr::read(&origin) };

    assert_eq!(copied, Value(1));
    assert_eq!(copied, origin);
}

/// test failed as expected: double free detected
#[test]
fn read_value_that_allocated_in_heap_will_result_in_double_free_problem() {
    let origin = Box::new(Value(1));
    let copied = unsafe { std::ptr::read(&origin) };

    assert_eq!(copied, Box::new(Value(1)));
    assert_eq!(copied, origin);
}


#[derive(Debug, PartialEq)]
struct Value<T>(T);
rust
3 Answers

The unsafe method you are using just creates a bitwise copy of the referenced value. When you do this with a Box, it's not okay but for something like your Value struct containing an integer, it is okay to make the copy as Drop of integers has no side effects while drop of Box accesses global allocator and changes the state.

If you do not understand any term I used for this explanation, try to search it or ask in the comments.

user_139953110

Those tests hide the fact that you use different types in them. It isn't really about stack or heap.

  1. In the first one you use Value<i32> type, which is your custom type, presumably without custom Drop implemented. If so, then Rust will call Drop on each member, in this case the i32 member. Which does nothing. And so nothing happens when both objects go out of scope. Even if you implement Drop, it would have to have some serious side-effects (like call to free) for it to fail.
  2. In the second one you actually use Box type, which does implement Drop. Internally it calls free (in addition to dropping the underlying object). And so free is called twice on drop, trying to free the same pointer (because of the unsafe copy).
user_6455510

This is not a double free because we do not free the memory twice. Because we do not free memory at all.

However, whether this is valid or UB is another question. Miri does not flag it as UB, however Miri does not aim to flag any UB out there. If Value<i32> was Copy, that would be fine. As it is not, it depends on the question whether std::ptr::read() invalidates the original data, i.e. is it always invalid to use a data that was std::ptr::read()'ed, or only if it violates Stacked Borrows semantics, like in the case of copying the Box itself where both destructors try to access the Box thereafter?

The answer is that it's not decided yet. As per UCG issue #307, "Are Copy implementations semantically relevant (besides specialization)?":

@steffahn

Overall, this still being an open question means that while miri doesn't complain, one should avoid code like this because it's not yet certain that it won't be UB, right?

@RalfJung

Yes.

In conclusion, you should avoid code like that.

user_78843050
Related