OpenMP multi-threading strange behavior

[Enigmatisms]

Problem

• When using flann::Index<flann::L2>::knnSearch with OpenMP enabled (8 threads in flannParam.cores), if another OpenMP parallelism clause is defined, I might receive segmentation fault, e.g.:

  void someFunction() {
  /// some code ....
  flannIndex.knnSearch(flann::Matrix<double>(query_data, point_num, 2), 
          nearestIdxMat, nearestDistMat, KNN, flannParam
   );
  /// ... some other code here
  #pragma omp parallel num_threads(8) 
  {
      #pragma omp for reduction(+:filtered_num, error, trans_error) 
      for (int i = 0; i < point_num; i++) {
          const auto& [err, trans_err] = icpSolution(knnIdx, knnDist, nnp,
              isValid, max_dist, i, all_change_ts, all_previous_ts, all_trans_weights);
          if (err >= 0.0 && trans_error >= 0.0) {
              error += err;
              trans_error += trans_err;
              filtered_num += 1;
           }
      }
  }
  /// some code ....
  }

  The code above will result in: computation failure of function knnSearch. The elements in knn id matrix (in the code above:nearestIdxMat) are all wrong. Note that:

• There is no data race or read-write conflict in my code (I suppose), the output of knnSearch is used in function icpSolution, which is a const class member function and all the inputs/outputs of it are guaranteed thread safety.
• GDB indicates behaviors like this: it seems like there are multiple someFunction() on the run, there are times that: after knnSearch() returned logically (as someFunction() is logically serialized), icpSolution() would still have race condition yet icpSolution() never writes in flann-related data.
• There is actually solution to the seg fault above: when I add #pragma omp critical to the place where I call someFunction(), the problem is resolved even though I think it is not elegant and makes no sense at all.
• There is some complement information generated from ThreadSanitizer

  ThreadSanitizer Output

• When using flann::Index<flann::L2>::knnSearch with OpenMP enabled (8 threads in flannParam.cores), data race warning always presents.

• Note that: in this situation, OpenMP is used only in flann::Index<flann::L2<double>>::knnSearch, no other openmp clause is used.

  
  WARNING: ThreadSanitizer: data race (pid=4696)
  Write of size 8 at 0x7ffef53a7158 by main thread:
  #0 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_length(unsigned long) /usr/include/c++/7/bits/basic_string.h:172 (VWICP+0x3391b)
  #1 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_set_length(unsigned long) /usr/include/c++/7/bits/basic_string.h:205 (VWICP+0x332fb)
  #2 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) /usr/include/c++/7/bits/basic_string.tcc:232 (VWICP+0x4d943)
  #3 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) /usr/include/c++/7/bits/basic_string.h:236 (VWICP+0x4123f)
  #4 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) /usr/include/c++/7/bits/basic_string.h:255 (VWICP+0x329f6)
  #5 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) /usr/include/c++/7/bits/basic_string.h:511 (VWICP+0x28257)
  #6 std::ostream& Eigen::operator<< <Eigen::Matrix<float, 4, 4, 0, 4, 4> >(std::ostream&, Eigen::DenseBase<Eigen::Matrix<float, 4, 4, 0, 4, 4> > const&) /usr/local/include/eigen3/Eigen/src/Core/IO.h:253 (VWICP+0x2e56c)
  #7 main /home/sentinel/test/VWICP.cpp:294 (VWICP+0x1c4c4)
  
  Previous read of size 8 at 0x7ffef53a7158 by thread T5:
  #0 flann::NNIndex<flann::L2<float> >::knnSearch(flann::Matrix<float> const&, flann::Matrix<unsigned long>&, flann::Matrix<float>&, unsigned long, flann::SearchParams const&) const [clone ._omp_fn.1] /usr/include/flann/algorithms/nn_index.h:350 (VWICP+0x1db36)
  #1 <null> <null> (libgomp.so.1+0x1696d)
  
  Location is stack of main thread.
  
  Location is global '<null>' at 0x000000000000 ([stack]+0x00000001f158)
  
  Thread T5 (tid=4831, running) created by main thread at:
  #0 pthread_create <null> (libtsan.so.0+0x2bcee)
  #1 <null> <null> (libgomp.so.1+0x16f5f)
  #2 flann::NNIndex<flann::L2<float> >::knnSearch(flann::Matrix<float> const&, flann::Matrix<int>&, flann::Matrix<float>&, unsigned long, flann::SearchParams const&) const /usr/include/flann/algorithms/nn_index.h:375 (VWICP+0x3c48a)
  #3 flann::Index<flann::L2<float> >::knnSearch(flann::Matrix<float> const&, flann::Matrix<int>&, flann::Matrix<float>&, unsigned long, flann::SearchParams const&) const /usr/include/flann/flann.hpp:260 (VWICP+0x2fbda)
  #4 main /home/sentinel/test/VWICP.cpp:198 (VWICP+0x1af19)

SUMMARY: ThreadSanitizer: data race /usr/include/c++/7/bits/basic_string.h:172 in std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_length(unsigned long)

### Question
- Why would these strange behaviors occur? Is `lib-flann` or `OpenMP` to be blamed?

[Enigmatisms]

P.S. There is actually solution is actually false. This doesn't solve my problem, knnSearch will still generate false result.

[Enigmatisms]

Never mind, OpenMP is to blame.