Double Free - Crash or No Crash

Double Free - crash or no crash

Because in C lingo, undefined behavior is just that: undefined. Anything might happen.

Also see man 3 free:

[…] if free(ptr) has already been called before, undefined behavior occurs.

Eigen static lib aligned_free double free or corruption

In case you compiled the library and the main executable with mismatching architecture flags (-m... flags for gcc), you can observe the crash. For example, when I compile the library with avx enabled (-mavx) and the main executable without avx, or vice versa, it crashes. The crash also occurs in Eigen 3.4.0. Moreover, it also occurs without optimization (-O0).

The Eigen aligned_malloc() and aligned_free() functions are doing different things depending on the value of the EIGEN_DEFAULT_ALIGN_BYTES macro, which has a different value when e.g. AVX (among others) is enabled or disabled. Eigen automatically selects the proper value depending on the used compiler flags. So, if you enable AVX only in the static library, the constructor of C uses handmade_aligned_malloc() internally, which is not returning the pointer received by malloc() directly but instead moves it a bit to ensure proper alignment. On the other hand, assigning a new value to C::v from the executable (which is compiled without AVX) will first try to free the memory by calling b->c.v.~VectorXd(), which then ends up calling just free() instead of handmade_aligned_free(). Thus, free() receives an address that does not point to the start of the allocated memory, which then causes the crash.
Of course, if you enable AVX in the executable and disable it in the library, you get mismatching calls to malloc() and handmade_aligned_free() instead, also resulting in a crash.

The solution is simple: Ensure that you compile the static library and the executable with the same architecture flags. If for whatever reason this is not possible, ensure that creation and destruction always happens in the same component. For example, you could make C::v private and allow modification of it only via functions that are implemented in the C.cpp file.

Note: Your other post is a bit different since it involves no dynamic memory management, while in the present post you use VectorXd which does use dynamic memory management.

Note 2: The described problem is unrelated to the use of std::shared_ptr. But for Eigen versions before 3.4.0 you might need to use EIGEN_MAKE_ALIGNED_OPERATOR_NEW to ensure that the pointer b is properly aligned, regardless of the architecture and C++17; at least the original Eigen issue was implemented only for 3.4.0. But I might be wrong on this.

Double-Free exercise doesn't act as expected

I am sorry for taking up people's time with this. I figured it out.
That crash behavior is supposed to be provided by dmalloc, however its usage has changed a little since the writing of the book I am reading.
I needed to add -DDMALLOC_FUNC_CHECK to the compiler options in order for it to produce the expected result.

I learned its dmalloc, not the OS that causes the program to crash when you double-free the pointer.

`double free or corruption (out)` error on a stack QDialog with the `WA_DeleteOnClose` attribute set

I've got the answer in the Qt Forum : link.

The source code for the QDialog class contains the following lines:

//QDialog::exec()

if (deleteOnClose)
    delete this;
return res;

which is, ofc, causes a crash if this points to a stack object.

---

Related Topics