I could maybe think of a libmesh-only case, but if you're willing to run MOOSE, you can run the moose/test/tests/geomsearch/nearest_node_locator/nearest_node_locator.i input file. It appears to reproduce the error every time (with --n-threads=2).
You're probably already aware of this, but for helgrind to be useful, you need to compile libMesh with --with-thread-model=pthread **and** you need to manually ensure that you don't define LIBMESH_HAVE_OPENMP in libmesh_config.h. (I have to manually comment those lines out because configure will always enable OpenMP if it can, regardless of the thread model specified). On Thu, May 9, 2019 at 8:59 PM Stogner, Roy H <royst...@ices.utexas.edu> wrote: > > On Thu, 9 May 2019, Alexander Lindsay wrote: > > > I'm getting the helgrind error below. Is this a false positive? > > My intuition says "no, this is a real bug", but I'm having trouble > figuring out what's really going on here. There's a race condition > between a read and a write to the same spot in the same PetscVector, > from two different threads working on the SortAndCopy::operator()? > But I don't immediately see how that's possible. That operator reads > from one PetscVector and writes to a different PetscVector. > > Can you set up a case that (at least usually) reproduces the problem? > > Thanks, > --- > Roy > _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
