Ok. So I am in the debugger and stepping through the code. The size of setup_cache in Singleton::setup() (line 84 of libMesh_singleton.C) is zero. So, the for loop is not doing anything.
-Manav > On Mar 11, 2015, at 10:12 AM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > > On Wed, 11 Mar 2015, Manav Bhatia wrote: > >> I am working on getting the stack trace. The problem is that if I >> comment the “lock” line out, then the code crashes with a >> segmentation-fault without a stack trace. There is, obviously, >> something that I am not doing right. > > No need to comment the lock line out. Try just sticking a call to > print_trace() before the line. > > Or if you want to get in there interactively: I know debugging in > parallel is a pain, but if you can exhibit the problem on a handful of > processors it can be done without expensive tools. Even in the worst > case (parallel, no "make install" yet) something like this should work: > > mpirun -np 2 xterm -e bash -c "libtool --mode=execute gdb --args > ./my_prog-dbg --my_options" > >> I was alluding towards the call immediately after the setup, which reads >> libmesh_assert(remote_elem); >> Sorry I have not been too clear and specific. > > Ah! I get it now. I was assuming you were failing an assertion in > remote_elem.C. Now I understand where you are, no need for a stack > trace. > > This is definitely baffling! It's probably worth it to get in the > debugger, then, so you can set some break points. See if > Singleton::setup_cache includes the RemoteElemSetup object, for > example. If so, see if RemoteElemSetup::setup() gets called. If not, > see if the Singleton::Setup::Setup() constructor is getting called > from the RemoteElemSetup::RemoteElemSetup() constructor. > >> I am at the following commit: abb4c2ffde19788495882db392f61fde18d365d3 > > That should be fine. > >> Is there a gcc vs icc thing here, perhaps? > > I don't think so. icc 11 is pretty old, but I used to use it > extensively, and it didn't have any problems with static object > constructors. > > It looks almost as if the TBB vs pthreads issue is a red herring too; > if we have an initialization order problem then that might just > trigger or not trigger depending on how objects happen to link on one > configuration vs another. > --- > Roy ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
