6 ms·

Double free is not necessary a C issue, but it can be also a program logic issue - I expect to have an object, but it's already deleted. So it's one of 1. obje

Double free is not necessary a C issue, but it can be also a program logic issue - I expect to have an object, but it's already deleted. So it's one of 1. object should not exist and the second free is incorrect 2. object should exist and the first free is incorrect 3. object existance is uncertain and the second free must somehow check that Although I can double-free only in unsafe languages, the wrong logic behind it can be the same in safe languages. It just have different consequences.

caconym_ 10y ago
I don't want to jump on the "Rust fixes everything" train, but lifetimes, scope-based destructors and reference counted pointers seem like they help with this sort of thing beyond just preventing literal accesses of freed memory; they can make sure objects are around when you need them and that they're destroyed automatically when you don't anymore. Of course, you don't get it all for free; you have to wrestle with mutability and lifetimes, which can get hairy.
xorblurb 10y ago
Of course it is a C issue, in the same sense that ALL logic errors are in the case you describe -- so either C issues do not exist or you did not manage to find the correct definition: for ex OOB access is caused by faulty program logic, and the consequences are dramatic in unsafe languages. That is an issue of the language, despite you being able to compute OOB indexes in any language. Same thing for double free; the language issue is that the result is catastrophic, not that you can write for ex faulty logic attempting a liberation too early, or an extra one. (Because in safe languages, the result is not as catastrophic as in unsafe languages). That is the whole concept of safety.
- mikulas_florek 10y ago
  Let's take some safe language, e.g. c# 1. object should not exist and the second free is incorrect In C# I can have to variables pointing to the same object, I null only one of them. The second should be nulled too, but it's not. That's a logic error. So in C# I end up with some object that should not be there, but it is. Which is better - doube-free or undestroyed object - depends on use case.
  - pjmlp 10y ago
    The big difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution. It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data. Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.
    - mikulas_florek 10y ago
      > Having a reference that the GC doesn't collect Using such object is/can be as dangerous. In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.
      - stymaar 10y ago
        > In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes) You don't know what an undefined behavior is, do you ? You cannot be sure it crashes since the compiler is allowed to do anything with the assumption it doesn't happen. It's absolutely legit for the compiler to remove all the code you added to check a double-free didn't happen because it is assuming that's dead code. See this post[1] from the LLVM blog which explains why you can't expect anything when you're triggering an UB. [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?m=1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
        mikulas_florek 10y ago
        I know very well what UB is and I bet there is not a single big program which does not have undefined behaviour. I even rely on UB sometimes, because with well defined set of compilers and systems, it's in reality well defined. I was talking in general about "unsafe" languages. I use c++ in my projects and use custom allocators everywhere, so there is no problem with UB there. The custom allocators also do the checking against double-free.

caconym_ 10y ago

I don't want to jump on the "Rust fixes everything" train, but lifetimes, scope-based destructors and reference counted pointers seem like they help with this sort of thing beyond just preventing literal accesses of freed memory; they can make sure objects are around when you need them and that they're destroyed automatically when you don't anymore. Of course, you don't get it all for free; you have to wrestle with mutability and lifetimes, which can get hairy.

xorblurb 10y ago

Of course it is a C issue, in the same sense that ALL logic errors are in the case you describe -- so either C issues do not exist or you did not manage to find the correct definition: for ex OOB access is caused by faulty program logic, and the consequences are dramatic in unsafe languages. That is an issue of the language, despite you being able to compute OOB indexes in any language. Same thing for double free; the language issue is that the result is catastrophic, not that you can write for ex faulty logic attempting a liberation too early, or an extra one. (Because in safe languages, the result is not as catastrophic as in unsafe languages). That is the whole concept of safety.

mikulas_florek 10y ago
Let's take some safe language, e.g. c# 1. object should not exist and the second free is incorrect In C# I can have to variables pointing to the same object, I null only one of them. The second should be nulled too, but it's not. That's a logic error. So in C# I end up with some object that should not be there, but it is. Which is better - doube-free or undestroyed object - depends on use case.
- pjmlp 10y ago
  The big difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution. It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data. Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.
  - mikulas_florek 10y ago
    > Having a reference that the GC doesn't collect Using such object is/can be as dangerous. In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.
    - stymaar 10y ago
      > In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes) You don't know what an undefined behavior is, do you ? You cannot be sure it crashes since the compiler is allowed to do anything with the assumption it doesn't happen. It's absolutely legit for the compiler to remove all the code you added to check a double-free didn't happen because it is assuming that's dead code. See this post[1] from the LLVM blog which explains why you can't expect anything when you're triggering an UB. [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?m=1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
      - mikulas_florek 10y ago
        I know very well what UB is and I bet there is not a single big program which does not have undefined behaviour. I even rely on UB sometimes, because with well defined set of compilers and systems, it's in reality well defined. I was talking in general about "unsafe" languages. I use c++ in my projects and use custom allocators everywhere, so there is no problem with UB there. The custom allocators also do the checking against double-free.