In the process of implementing a fix for #181, MR !1239 has been opened and is resulting in multiple segfaults on different executables when running tests on macOS. When running the pipeline for both osx-default and osx-full > 100 tests fail, e.g. see [job 70680](https://gitlab.nektar.info/nektar/nektar/-/jobs/70680). Failing executables include `FieldConvert`, `IncNavierStokesSolver`, `Helmholtz1D/2D/3D`, etc. Example error: ``` 642/654 Test #644: MultiRegions_Helmholtz3D_HDG_Hex_AllBCs ...........................................***Failed 0.05 sec sh: line 1: 46211 Segmentation fault: 11 /Users/gitlab-runner/builds/d6W2xxpM/0/nektar/nektar/build/library/Demos/MultiRegions/HDGHelmholtz3D Helmholtz3D_Hex_AllBCs_P6.xml > output.out 2> output.err Error occurred running test: Command: /Users/gitlab-runner/builds/d6W2xxpM/0/nektar/nektar/build/library/Demos/MultiRegions/HDGHelmholtz3D Helmholtz3D_Hex_AllBCs_P6.xml 1>output.out 2>output.err ``` Gitlab Mac runner: OS: ``` ProductName: Mac OS X ProductVersion: 10.11 BuildVersion: 15A284 ``` Compiler: ``` Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix ``` On newer Mac systems, e.g. 10.15, clang Apple clang version 11.0.3 (clang-1103.0.32.62), the tests complete successfully. This led us to assume that there is a possible issue with the older clang version on the gitlab runner. The following is possible related: [https://stackoverflow.com/questions/30830848/c-segfault-on-one-platform-macosx-but-not-another-linux](https://stackoverflow.com/questions/30830848/c-segfault-on-one-platform-macosx-but-not-another-linux) We narrowed down the issue to a problem in `MeshGraph.cpp`. The issue is related to creation of the `DefaultVar` entry in the `m_expansionMapShPtrMap` if there is no `DefaultVar` entry set by the user. When attempting to assign the pointer from the first entry in `m_expansionMapShPtrMap` to be the pointer for the `DefaultVar`, the assignment is failing resulting in the `DefaultVar` entry having a null pointer. This also results in `m_expansionMapShPtrMap.begin()->second` which previously contained the valid pointer for the first map entry being set to 0. Since this occurs only on this specific machine, we assume a compiler issue but have implemented a fix which will work on all platforms. Original code: ``` m_expansionMapShPtrMap["DefaultVar"] = m_expansionMapShPtrMap.begin()->second; ``` This somehow resulted in `m_expansionMapShPtrMap.begin()->second` being set to 0 and therefore the first map entry AND the `DefaultVar` entry having a null pointer for their map entry. We (@cjane and @jhc02) have resolved this (with assistance from @ccantwel) by first storing the pointer address to a separate variable and then using this to assign the pointer for the `DefaultVar` entry: ``` ExpansionInfoMapShPtr firstEntryAddr = m_expansionMapShPtrMap.begin()->second; m_expansionMapShPtrMap["DefaultVar"] = firstEntryAddr; ```