Segfault on multiple tests on macOS
In the process of implementing a fix for #181 (closed), MR !1239 (merged) 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.
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
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;