Thank you very much for the notes.
The Eigen code I see does everything with the preprocessor. Which is
fine, and doesn't mean that it must crash. For the specific package I'm
building (libg2o) Eigen is the only option, but this sounds like a
generic problem that affects all sorts of packages, not just libg2o. I'm
a bit surprised that we don't have obvious bug reports related to this.
There are lots of reports of crashes on various github pages, with the
replies being "you must match build flags, especially -m....". So this
isn't a completely unknown problem.
I've seen two kinds of crashes so far:
- Mismatched alloc/free. This is described in the first email in this
thread
- Mismatched alignment. Something calls aligned_malloc() to get a
pointer with some alignment. And some other Eigen function then
ingests this pointer and asserts because it isn't aligned sufficiently
(this second function was compiled differently). I've seen this happen
here:
https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/MapBase.h/#L198
A number of structures in Eigen are aligned to "AlignedMax", defined
here:
https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/util/Constants.h/#L241
Which eventually comes from EIGEN_IDEAL_MAX_ALIGN_BYTES, defined here:
https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/util/ConfigureVectorization.h/#L57
I can imagine there are other crashes that we could get. And I'm also
suspecting that simply limiting libg2o Eigen calls to implementations
inside libg2o won't conclusively fix everything. Probably what we should
do is:
- patch the Eigen alloc/free functions to do a consistent thing
- patch Eigen to set EIGEN_IDEAL_MAX_ALIGN_BYTES to a constant maximum
I should run more experiments, though.
Thanks
