I did a lot of testing with dbg and opt builds. The issue seems to be some optimization flag activated by -march=native when compiling my own code. Leaving this out resolves all of the spurious memory errors, which were probably the result of Eigen's fussiness about alignment. The performance gain in the cases where it worked was pretty minimal, so I don't really feel like sorting through the list of flags to find the troublemakers. I wouldn't worry about your implementation; the issue seems to be my own code, and I have a habit of breaking things.
Regards, Bailey On Thu, Feb 13, 2020 at 5:58 PM John Peterson <jwpeter...@gmail.com> wrote: > > > On Thu, Feb 13, 2020 at 10:41 AM Roy Stogner <royst...@ices.utexas.edu> > wrote: > >> >> On Thu, 13 Feb 2020, Bailey Curzadd wrote: >> >> > /usr/local/lib/libmesh_opt.so.0 >> >> Well, this is the first thing you'll want to change. Often times a >> bug that exhibits as an incomprehensible segmentation fault in opt >> mode will instead trigger a sensible assertion failure in dbg mode. >> > > In addition to compiling in dbg mode, which is a great suggestion, you may > also want to see if you can reproduce the error with a very stripped down > Eigen-only example. We don't do anything particularly controversial with > our Eigen wrappers, for example the EigenSparseLinearSolver does not even > appear to have any "state" which could get messed up between solves. So I > think it's likely that the error is in Eigen itself and you'll need to get > help from those devs, who will likely want an Eigen-only example. > Of course, now that I've said that, we'll probably figure out that it's our > fault somehow :_[ > > -- > John > _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
