Segmentation fault compiling large array with warning

[sbronson]

array [1..10000] of 1..1: A = [let {var 1..2: A = 1} in 1 | i in 1..10000];

Warning: variable `A` shadows variable with the same name in line 1.27
MiniZinc error: Memory violation detected (segmentation fault).
This is a bug. Please file a bug report using the MiniZinc bug tracker.
Aborted

valgrind

==11275== Invalid read of size 1
==11275==    at 0x4848C66: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==11275==    by 0x1E71F8: length (char_traits.h:371)
==11275==    by 0x1E71F8: operator<< <std::char_traits<char> > (ostream:612)
==11275==    by 0x1E71F8: operator<< <char, std::char_traits<char> > (aststring.hh:110)
==11275==    by 0x1E71F8: std::basic_ostream<char, std::char_traits<char> >& MiniZinc::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, MiniZinc::Location const&) (ast.hh:223)
==11275==    by 0x3B4313: MiniZinc::Warning::print(std::ostream&, bool) const (warning.cpp:22)
==11275==    by 0x24107B: MiniZinc::Env::dumpWarnings(std::ostream&, bool, bool, int) (flatten.cpp:1557)
==11275==    by 0x331444: MiniZinc::CompilePass::run(MiniZinc::Env*, std::ostream&) (compile_pass.cpp:175)
==11275==    by 0x2BFFDF: MiniZinc::Flattener::multiPassFlatten(std::vector<std::unique_ptr<MiniZinc::Pass, std::default_delete<MiniZinc::Pass> >, std::allocator<std::unique_ptr<MiniZinc::Pass, std::default_delete<MiniZinc::Pass> > > > const&) (flattener.cpp:452)
==11275==    by 0x2C4681: MiniZinc::Flattener::flatten(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (flattener.cpp:788)
==11275==    by 0x16AA23: MiniZinc::MznSolver::flatten(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver.cpp:904)
==11275==    by 0x171C0D: MiniZinc::MznSolver::run(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver.cpp:989)
==11275==    by 0x166B76: (anonymous namespace)::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) (minizinc.cpp:41)
==11275==    by 0x165667: main (minizinc.cpp:126)
==11275==  Address 0x38 is not stack'd, malloc'd or (recently) free'd

On develop.

[Dekker1]

While looking into this issue I discovered that both Warning and LocationException classes in the implementation of the MiniZinc compiler do not necessarily mark the Location object that they use as alive. This means that if the expressions that was referred to by the warning/error is removed, and garbage collection is triggered before the output of said warning/error, then the string that the Location object refers to might not exist anymore.

The solution is of course to mark these as alive, I'll put in an initial fix, but we might reconsider how to do this if there is a more efficient way to mark them as such.