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 following program will segfault, double free, leak, and generally misbehave:
type T = {mut f: @int};
fn foo(++x: T) { x.f = @4; }
fn main() {
let x = {mut f: @3};
foo(x);
}
The reason is our by-value protocol: we copy the data for the record but do not invoke the take-glue (nor drop-glue). As a result, the assignment x.f = @4 within foo() causes the original @3 to be freed, but never arranges for the new @4 to be released. When foo() returns, main() tries to drop its copy of x, which still contains the original @3 pointer.
Of course the same badness would happen if the type T included a unique pointer. Or really anything that requires take/drop-glue.
The text was updated successfully, but these errors were encountered:
should we keep by-value mode (and I could see that it might be a good idea for performance), one solution I could institute easily enough is for borrowck to forbid modifications to interior data of a by-val mode argument
add very basic Android support
This is just enough to print to stdout. I won't push this any further, but having these basics should hopefully make it easier for others to do so.
Also slightly improve threading support on FreeBSD while we are at it.
Partially based on rust-lang/miri#2011.
Fixesrust-lang/miri#2010.
celinval
added a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
Kani compiler will now only store KaniMetadata after compiling all harnesses. Before, we were storing before codegen in the first iteration of the compiler.
This will still allow us to generate metadata without actually performing codegen, if we ever implement a `kani list` subcommand. The metadata won't be stored though if Kani fails to codegen. However, we don't do anything extra with that file if the compilation fails.
This change is required for rust-lang#2493 and contracts work. This will allow us to store information collected during code generation.
The following program will segfault, double free, leak, and generally misbehave:
The reason is our by-value protocol: we copy the data for the record but do not invoke the take-glue (nor drop-glue). As a result, the assignment
x.f = @4
withinfoo()
causes the original@3
to be freed, but never arranges for the new@4
to be released. Whenfoo()
returns,main()
tries to drop its copy ofx
, which still contains the original@3
pointer.Of course the same badness would happen if the type T included a unique pointer. Or really anything that requires take/drop-glue.
The text was updated successfully, but these errors were encountered: