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.
Valgrind confirms the confusing part: the choice of solver in the function for step #3 (even the choice of the matrix type template parameter), causes a memory error in the solver used in step #1. Would you guys have any idea why changing the type of an Eigen solver external to the libMesh library would cause a memory error in the internal solver before the external solver even comes into scope?
This technically *could* be an effect of opt mode, since optimizing compilers are allowed to do all sorts of reordering, under the rule of "if the user code invokes undefined behavior the compiler isn't obligated to care what happens next", but it seems unlikely to me - usually your initialization (assuming you're being literal with the word "scope" makes some function calls across compilation objects, forcing the compiler to be conservative in case those calls have side effects. Eigen is pretty much header-only, so maybe it's not impossible that the compiler really is reordering like crazy in opt mode, but our *shims* to Eigen still force calls to code in .C files. --- Roy _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
