Data is stored in a certain location in memory, and when it's no longer needed, that memory is freed. (by most languages, this is the garbage collector. In C you have to do this manually. I'm not sure how this works in rust) If you try and use some memory after it no longer exists, that's use-after-free and will cause a crash (I think a segfault)

@@Ash-qp2yw the rust compiler ensures that if you only ever use safe rust, then it is impossible to free an object that is currently in use. for instance in order to call `drop` on a value (which would free it) you need to move that value into the function, and you cannot move a value while there also exists a reference to it. the only way a use after free could happen is if you use some unsafe code to free it while it still exists, or dereference a raw pointer to it after it has been freed as the compiler doesn't keep track of raw pointers at all.

The reason use after free is really bad is that after memory has been freed, it could have any literally any value since that memory could have been reused or overwritten. And "any value" includes values that aren't valid for the variable's type. As a simple example you might have an enum for the seven days of the week, and after the memory is freed you could end up with a nonsense value that's not one of the seven you defined. If the data was a pointer, you could end up with a pointer to a completely random address. If the program doesn't crash, it'll behave unpredictably and a clever attacker might even be able to exploit the bug to do things like run code of their own.

I think the problem is getting the slice of bytes out at the end. The Finalizer is attached to the struct which is not associated with the slice at all. So GC will happily call the free method attached to the finalizer which calls into Rust to clear out all memory which also removes the memory the slices of bytes points to.