Segmentation fault since 3a0c34be01c94303beb6c403a93e60581a8e3aeb

[loeiten]

Commit 3a0c34b gives a segmentation fault. If the current block != NULL.

This segmentation fault occurs in SOLVE_FOR(...) if mms=false (for example when running the test-wave/ example).

A semi stack-trace looks like this

=> SOLVE_FOR(...)
=> inital_profile(name, v);    in Solver::add
=> var = scale*f.create3D(s, varOpts, NULL, loc);    in int initial_profile(const char *name, Field3D &var)
=> return rhs * lhs;    in const Field3D operator*(const BoutReal lhs, const Field3D &rhs)
=> Field3D result = *this;    in const Field3D Field3D::operator*(const BoutReal rhs) const
=> * this=f;     in Field3D::Field3D(const Field3D& f) : background(NULL), deriv(NULL), yup_field(0), ydown_field(0)
=>  if(block != NULL)
        freeData();   in Field3D & Field3D::operator=(const Field3D &rhs)
=> block->refs--;    in void Field3D::freeData()

Notice that if mms=true, inital_profile(...) is never called, and for that reason the commit has passed the keen eyes of our good friend travis.

In addition to fixing the problem, I suggest to somehow make the SOLVE_FOR for mms=false more equal to the mms=true case, or to add for example the test-wave/ example to the test_suite in order to avoid bugs like this in the future.

[bendudson]

Sorry everyone, I should have checked this more thoroughly before merging. I'm a little worried that the test suite still passed, since it includes many cases with mms=false. The bug was due to a test
"if(block != NULL)" when block was uninitialised, so it's possible that the tests were just lucky and block was always 0.

Fixed for now, but a better solution is in the mesh/next branch, where this memory management is greatly simplified using Array<>.