Pylith issue - when running greens functions for a 3D fault example. We thought it was related to having a zero-dimensional spatialdb for the impulses but the error is still there when we made the spatialdb 1-dimensional.
Not a critical bug because the greensfns are still created, error happens at the very end of the pylith run.
Result of running with ‘valgrind --trace-children=yes pylith step05_greensfns.cfg’:
/opt/pylith/dest-debug/lib/python3.10/site-packages/pylith/problems/Problem.py:190:initialize
-- greensfns(info)
-- Initializing greensfns problem with quasistatic formulation.
==24874== Invalid write of size 4
==24874== at 0x1037FAD8: pylith::faults::_FaultCohesiveImpulses::findImpulsePoints(std::valarray<int>*, pylith::topology::Field const&, double) ([FaultCohesiveImpulses.cc:497](http://faultcohesiveimpulses.cc:497/))
==24874== by 0x1037725B: pylith::faults::FaultCohesiveImpulses::createAuxiliaryField(pylith::topology::Field const&, pylith::topology::Mesh const&) ([FaultCohesiveImpulses.cc:257](http://faultcohesiveimpulses.cc:257/))
==24874== by 0x103B7477: pylith::feassemble::Integrator::initialize(pylith::topology::Field const&) ([Integrator.cc:153](http://integrator.cc:153/))
==24874== by 0x103F1E43: pylith::feassemble::IntegratorInterface::initialize(pylith::topology::Field const&) ([IntegratorInterface.cc:445](http://integratorinterface.cc:445/))
==24874== by 0x106343B3: pylith::problems::Problem::initialize() ([Problem.cc:425](http://problem.cc:425/))
==24874== by 0x106750E7: pylith::problems::GreensFns::initialize() ([GreensFns.cc:199](http://greensfns.cc:199/))
==24874== by 0x1DFE5A63: _wrap_Problem_initialize (problems_wrap.cxx:4313)
==24874== by 0x49B544F: ??? (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874== by 0x490906F: _PyEval_EvalFrameDefault (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874== by 0x4A48BF3: ??? (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874== by 0x490906F: _PyEval_EvalFrameDefault (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874== by 0x4A48BF3: ??? (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874== Address 0xb26b0f0 is 0 bytes after a block of size 400 alloc'd
==24874== at 0x48657B8: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==24874== by 0x1031FCEB: int* std::__valarray_get_storage<int>(unsigned long) (valarray_array.h:58)
==24874== by 0x1031F61B: std::valarray<int>::resize(unsigned long, int) (valarray:1042)
==24874== by 0x1037F83B: pylith::faults::_FaultCohesiveImpulses::findImpulsePoints(std::valarray<int>*, pylith::topology::Field const&, double) ([FaultCohesiveImpulses.cc:488](http://faultcohesiveimpulses.cc:488/))
==24874== by 0x1037725B: pylith::faults::FaultCohesiveImpulses::createAuxiliaryField(pylith::topology::Field const&, pylith::topology::Mesh const&) ([FaultCohesiveImpulses.cc:257](http://faultcohesiveimpulses.cc:257/))
==24874== by 0x103B7477: pylith::feassemble::Integrator::initialize(pylith::topology::Field const&) ([Integrator.cc:153](http://integrator.cc:153/))
==24874== by 0x103F1E43: pylith::feassemble::IntegratorInterface::initialize(pylith::topology::Field const&) ([IntegratorInterface.cc:445](http://integratorinterface.cc:445/))
==24874== by 0x106343B3: pylith::problems::Problem::initialize() ([Problem.cc:425](http://problem.cc:425/))
==24874== by 0x106750E7: pylith::problems::GreensFns::initialize() ([GreensFns.cc:199](http://greensfns.cc:199/))
==24874== by 0x1DFE5A63: _wrap_Problem_initialize (problems_wrap.cxx:4313)
==24874== by 0x49B544F: ??? (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874== by 0x490906F: _PyEval_EvalFrameDefault (in /usr/lib/aarch64-linux-gnu/libpython3.10.so.1.0)
==24874==
valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 464, hi = 923417968855.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.