Multi-thread issue with stateful materials #1321
Comments
|
There are definitely some issues with stateful material properties. If I run stateful_prop_test through valgrind it shows me quite a few things that are leaked (see below). We should clean this stuff up first... |
|
Moving this down from Blocker... it's not truly blocking although it does need to be fixed. |
|
This problem is most likely due to the fact that you do not initialize your stateful properties, which you later access. We are still working on We'll take a look at this again once we have material properties working during initialSetup
|
|
In 49f78e1: |
|
In 14e81cd: |
permcody
added a commit
that referenced
this issue
Feb 14, 2014
permcody
added a commit
that referenced
this issue
Feb 14, 2014
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This multi-thread issue seems related to the stateful material. I have a test case checked in
rattlesnake/examples/GODIVA/godiva_thread.i
If I run the problem on my mac with:
gdb --args ../../rattlesnake-dbg -i godiva_thread.i --n-threads=12
I got the error and the backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000005b0
to process 72566 thread 0x4403
0x000000010128b4b6 in MaterialPropertyStorage::initStatefulProps (this=0x104827a40, material_data=@0x104577730, mats=@0x106999318, n_qpoints=8, elem=@0x1045527f0, side=0) at MaterialPropertyStorage.C:102
102 if (props()[== NULL) props()elem_id[= material_data.props()prop_id->init(n_qpoints);
(gdb) bt
#0 0x000000010128b4b6 in MaterialPropertyStorage::initStatefulProps (this=0x104827a40, material_data=@0x104577730, mats=@0x106999318, n_qpoints=8, elem=@0x1045527f0, side=0) at MaterialPropertyStorage.C:102
#1 0x0000000100f62e93 in ComputeMaterialsObjectThread::onElement (this=0x1047d7158, elem=0x1045527f0) at ComputeMaterialsObjectThread.C:74
#2 0x0000000100eedea3 in ThreadedElementLoop<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*> >::operator() (this=0x1047d7158, range=@0x11bd06ac0) at ThreadedElementLoop.h:122
#3 0x0000000101001ccb in tbb::interface6::internal::start_reduce<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>, ComputeMaterialsObjectThread, tbb::auto_partitioner const>::run_body (this=0x1047d6940, r=@0x11bd06ac0) at parallel_reduce.h:152
#4 0x0000000101002219 in tbb::interface6::internal::partition_type_basetbb::interface6::internal::auto_partition_type::execute<tbb::interface6::internal::start_reduce<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>, ComputeMaterialsObjectThread, tbb::auto_partitioner const>, libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*> > (this=0x1047d6988, start=@0x1047d6940, range=@0x1047d6950) at partitioner.h:265
#5 0x0000000100fdb101 in tbb::interface6::internal::start_reduce<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>, ComputeMaterialsObjectThread, tbb::auto_partitioner const>::execute (this=0x1047d6940) at parallel_reduce.h:164
#6 0x000000010364b555 in tbb::internal::custom_schedulertbb::internal::IntelSchedulerTraits::local_wait_for_all ()
#7 0x0000000103647f6b in tbb::internal::arena::process ()
#8 0x00000001036456e0 in tbb::internal::market::process ()
#9 0x0000000103641b75 in tbb::internal::rml::private_worker::thread_routine ()
#10 0x00007fff8ae2f8bf in _pthread_start ()
#11 0x00007fff8ae32b75 in thread_start ()
If I run the problem with 6 threads, some time it's ok, some time I got segmentation fault. Any idea?
The text was updated successfully, but these errors were encountered: