5 ms·

See https://users.rust-lang.org/t/bronze-gc-and-aliasing-problems/65679 https://users.rust-lang.org/t/bronze-gc-and-aliasing-problem.... The GC allows use after

See https://users.rust-lang.org/t/bronze-gc-and-aliasing-problems/65679 https://users.rust-lang.org/t/bronze-gc-and-aliasing-problem.... The GC allows use after free bugs that are compile time exceptions in Rust.

p0nce 5y ago
Quoting the article: > those who [used the GC] required only about a third as much time (4 hours vs. 12 hours). Surely you can devote a chunk of your newfounded time to find use-after-free bugs.
- adgjlsfhk1 5y ago
  If that worked, people wouldn't still be finding use after free bugs in commonly used C libraries. The whole reason to use Rust is that it turns most of C's UB into compile time errors so that your code isn't horribly broken in the first place.
- notriddle 5y ago
  I don't know how to find use-after-free bugs in arbitrary code, no matter how much time I devote to the task. I just can't keep enough state in my head at once.
bjourne 5y ago
But the gc is there to test the usability cost of Rust's memory management scheme. A properly written gc would of course not allow for use-after-free bugs.
- adgjlsfhk1 5y ago
  The problem is that this study is relatively worthless, because the API used by this GC inherently introduces UB. If you have a correct API, the usability tradeoff might be very different.
  - bjourne 5y ago
    Can you please point to some results in the study that would have been different if the tracing gc hadn't suffered from use-after-free bugs?
    - adgjlsfhk1 5y ago
      The problem isn't that the GC suffered from use after free. The problem is that the GC allowed the user to have 2 references to a mutable object which is UB in Rust (and a compile time error without unsafe code). The problem with the API is that without some pretty fundamental changes to the language, the only times a GC doesn't error, and Rust does is when the user tries to do undefined behavior. Removing the UB is also pretty much impossible because if you allow these references, you remove one of the main tools the Rust compiler uses to optimize code.
      - bjourne 5y ago
        Having simultaneous mutable references to an object is UB in Rust because the memory manager cannot detect use-after-free errors. What you are talking about is not a feature but a limitation of Rust's borrow checker. But when using a gc multiple multiple references it not a problem at all so there is no reason to prevent it. This has almost nothing to do with performance. Restricting the number of mutable references to one does not mean that the compiler can emit significantly faster code.
        steveklabnik 5y ago
        > Having simultaneous mutable references to an object is UB in Rust This is correct. > because the memory manager cannot detect use-after-free errors. ... this is not. It is UB because the language declares it UB. It is absolutely to the core of the design of the language itself. All Rust code relies on this property to work. Something that breaks it is in fact broken, regardless of any other aspect of the program.
    - steveklabnik 5y ago
      To phrase what my sibling commentor said but in a different way: This paper is an experiment to see if a particular API could make using Rust easier. This specific API is not sound. This means that the paper's results are kind of irrelevant in a strict sense; this API cannot work in Rust, so it being easier is kind of a moot point. Maybe someone can take their API, make it sound, and then try again, and that's certainly good. But it is a serious flaw in the methodology. Specifically, this API call is unsound: GcRefCell<T>::as_mut(&self) -> &mut T It's not about the internals of the GC. It's about the API that it exposes to users. The author has some ideas: https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939502926 https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939... These ones are straightforward, and would probably work, but they would also introduce some friction, and removing friction is the entire point of the exercise. Is it too much? Maybe! It also maybe isn't. You'd need another study to figure that out.
Lerc 5y ago
What does "use after free" mean in a garbage collected environment? Isn't the purpose of GC to automatically free after last use.
- adgjlsfhk1 5y ago
  It means the GC design is fundamentally broken.

p0nce 5y ago

Quoting the article: > those who [used the GC] required only about a third as much time (4 hours vs. 12 hours). Surely you can devote a chunk of your newfounded time to find use-after-free bugs.

adgjlsfhk1 5y ago
If that worked, people wouldn't still be finding use after free bugs in commonly used C libraries. The whole reason to use Rust is that it turns most of C's UB into compile time errors so that your code isn't horribly broken in the first place.
notriddle 5y ago
I don't know how to find use-after-free bugs in arbitrary code, no matter how much time I devote to the task. I just can't keep enough state in my head at once.

bjourne 5y ago

But the gc is there to test the usability cost of Rust's memory management scheme. A properly written gc would of course not allow for use-after-free bugs.

adgjlsfhk1 5y ago
The problem is that this study is relatively worthless, because the API used by this GC inherently introduces UB. If you have a correct API, the usability tradeoff might be very different.
- bjourne 5y ago
  Can you please point to some results in the study that would have been different if the tracing gc hadn't suffered from use-after-free bugs?
  - adgjlsfhk1 5y ago
    The problem isn't that the GC suffered from use after free. The problem is that the GC allowed the user to have 2 references to a mutable object which is UB in Rust (and a compile time error without unsafe code). The problem with the API is that without some pretty fundamental changes to the language, the only times a GC doesn't error, and Rust does is when the user tries to do undefined behavior. Removing the UB is also pretty much impossible because if you allow these references, you remove one of the main tools the Rust compiler uses to optimize code.
    - bjourne 5y ago
      Having simultaneous mutable references to an object is UB in Rust because the memory manager cannot detect use-after-free errors. What you are talking about is not a feature but a limitation of Rust's borrow checker. But when using a gc multiple multiple references it not a problem at all so there is no reason to prevent it. This has almost nothing to do with performance. Restricting the number of mutable references to one does not mean that the compiler can emit significantly faster code.
      - steveklabnik 5y ago
        > Having simultaneous mutable references to an object is UB in Rust This is correct. > because the memory manager cannot detect use-after-free errors. ... this is not. It is UB because the language declares it UB. It is absolutely to the core of the design of the language itself. All Rust code relies on this property to work. Something that breaks it is in fact broken, regardless of any other aspect of the program.
  - steveklabnik 5y ago
    To phrase what my sibling commentor said but in a different way: This paper is an experiment to see if a particular API could make using Rust easier. This specific API is not sound. This means that the paper's results are kind of irrelevant in a strict sense; this API cannot work in Rust, so it being easier is kind of a moot point. Maybe someone can take their API, make it sound, and then try again, and that's certainly good. But it is a serious flaw in the methodology. Specifically, this API call is unsound: GcRefCell<T>::as_mut(&self) -> &mut T It's not about the internals of the GC. It's about the API that it exposes to users. The author has some ideas: https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939502926 https://github.com/mcoblenz/Bronze/issues/2#issuecomment-939... These ones are straightforward, and would probably work, but they would also introduce some friction, and removing friction is the entire point of the exercise. Is it too much? Maybe! It also maybe isn't. You'd need another study to figure that out.

Lerc 5y ago

What does "use after free" mean in a garbage collected environment? Isn't the purpose of GC to automatically free after last use.

adgjlsfhk1 5y ago
It means the GC design is fundamentally broken.