Dear Roy, I hope this does not come too late. But I finally got the debugger to work with some help of support on the Supercomputer that we are using. This is the complete stack:
To recap the problem: We were reading in a mesh that was created outside of libmesh (rectilinear) and wanted to use that in the context of the MOOSE framework. Before calling the function prepare_for_use we wanted to make sure that the ghost elements for the neighbouring processes were found. This seemed to work fine when compiled and run in opt mode but caused the code to get stuck when done so in dbg mode (no crash, just a running but hung-up executable). So this is the complete stack of what is happening. It seems like MPI_Probe is blocking the code for some reason that it is not getting its message on one of the processes. Have you ever come across something like that? –Barna > On 13 Jan 2017, at 17:04, Roy Stogner <royst...@ices.utexas.edu> wrote: > > > On Fri, 13 Jan 2017, Barna Becsek wrote: > >> Hmm, you are right but I cannot find a process that would correspond to the >> children of any of these. > > Is this a cluster, by any chance? Where slurm is running on the login > node but the actual applications are running on separate compute > nodes? > > If I'm right, then I'd recommend testing on a simple workstation > first, just to make debugging easier. Even if you only have 2 or 4 > cores you can still "mpirun -np 8" if that's what's necessary to > trigger the bug. > --- > Roy ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
