<div dir="ltr">Hi, I'm new here. Fixed an interesting segfault today. Here's how it goes.<div><br></div><div>I have a std::map of the following struct:</div><div><br></div><div><div><font face="monospace">struct State {<br>    size_t a;<br>    boost::posix_time::ptime b;</font></div><div><font face="monospace">    bool c;</font></div><div><font face="monospace">    bool d;<br>};</font></div></div><div><font face="monospace">std::map<std::string, State> myMap;</font></div><div><br></div><div>Then I do a find-or-create operation and take a reference to the result:</div><div><br></div><div><font face="monospace">std::string key = arbitraryString();</font></div><div><font face="monospace">State& s = myMap[key];</font></div><div><br></div><div>Now, as long as I only touch the first two members of the struct, all is rosy.</div><div><font face="monospace">s.a++;</font></div><div><font face="monospace">s.b = boost::posix_time::microsec_clock::universal_time();</font></div><div><br></div><div>But I found that as soon as I touched `<font face="monospace">s.c</font>` or `<font face="monospace">s.d</font>`, a segfault occurs at `<font face="monospace">State& s = myMap[key];</font>`:</div><div><br></div><div><font face="monospace">if (!s.c) { ... // Eventually causes a segfault at the assignment of s. Before the segfault, the value of s.c is often random data and not the expected value.</font></div><div><br></div><div>While this segfault is spurious, it is frequent enough to reproduce reliably.</div><div>Unfortunately, this may be impractical to reproduce for many of you as it only crashed on two of our armv7 hosts: a Motorola G6, and a Samsung J6. arm64 hosts appear to be unaffected.</div><div><br></div><div>My suspicion is that a temporary struct is being created with `myMap[key]`, and the reference of that is being returned before it is added to the map, but the memory is invalidated shortly after.</div><div><br></div><div>It could be related to caching/register optimization, as the issue doesn't happen if `<font face="monospace">State::c`</font> and `<font face="monospace">State::d`</font> are declared before `<font face="monospace">State::a`</font>.</div><div><br></div><div>The issue doesn't occur in `<font face="monospace">std::unordered_map</font>`.</div><div><br></div><div>Clang details:</div><div>Android (5220042 based on r346389c) clang version 8.0.7 (<a href="https://android.googlesource.com/toolchain/clang">https://android.googlesource.com/toolchain/clang</a> b55f2d4ebfd35bf643d27dbca1bb228957008617) (<a href="https://android.googlesource.com/toolchain/llvm">https://android.googlesource.com/toolchain/llvm</a> 3c393fe7a7e13b0fba4ac75a01aa683d7a5b11cd) (based on LLVM 8.0.7svn)<br>Target: armv7a-unknown-linux-android29<br>Thread model: posix<br></div><div><br></div><div>libc++ details:</div><div>Actually I really don't know how to get this. Help:</div><div><font face="monospace">ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-readelf -a ./ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++.so.28<br>readelf: Error: ./ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++.so.28: Failed to read file header</font><br></div><div><br></div><div>Is anyone able to confirm? What more information do I need to collect?</div></div>