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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
