title: The same code running with Mac Clang but crashes with Unix GCC
body: <p>I have a bizarre issue for code that I am running; The difficulty is that its not mine and its 
  quite a sizable code with various functions and headers,</p>
  
  <p>quick fact</p>
  
  <p>1.) Runs on my Mac machine compiler: Apple clang version 11.0.0</p>
  
  <p>2.) Crashes on my Unix machine with gcc 6.3.0 or higher</p>
  
  <hr>
  
  <p>Debugging:</p>
  
  <p>Using the gdb tool the crash happens on a simple line std::string line="";
  With error:
     "reporting free(): <strong>invalid next size (normal):...</strong>;"</p>
  
  <hr>
  
  <p>As I said the code is huge but let me try to give some specifics. This happens in a function</p>
  
  <pre><code>void read_data(std::string filename, number_type &amp; impact_parameter, number_type &amp;    n_participants, number_type &amp; multiplicity){
  
          std::ifstream infile(filename);
          std::string line="";
  
          size_type counter_numbers = 0;
          size_type counter_lines = 0;
          while (infile)
          {
              std::getline(infile, line); // Read in current line
              and so on...
  </code></pre>
  
  <p>The files that are read are of format:</p>
  
  <pre><code># event 0
  # b     = 10.63639744
  # npart = 95
  and so on...
  </code></pre>
  
  <p>It will read through the second line 
      current = 10.63639744 then going on next line it crashes,</p>
  
  <pre><code>*** Error in `./MultB': free(): invalid next size (normal): 0x0000000001fb9760 ***
  </code></pre>
  
  <p>I would really appreciate some help on this. Is this a compiler issue (Macchiato's vs Unix) or something can be done with this, </p>
  
  <p>thanks, Damir</p>
  
  <p>--------------- Update-------------------</p>
  
  <p>It seems the gdb didn't help much to locate the memory bug in the code; 
  I chopped up the code to what fraction of the code would work. </p>
  
  <p>Again, not being able to post the complete code (comprised of many headers and function) it appears the code would actually not have the "heap issue" if in the main class I dismiss initialization of some member variables /* stuff*/,</p>
  
  <pre><code>public:
   .
   .
   , r_interpolators_(0)
   , r_splines_(0)
   , racc_(0)
   , Nm_(128)
   , Nr_(size_type(grid_max/grid_step))
   , W_interpolators_(0)
   , W_splines_(0)
   , W_acc_(0)
   , normalizations_(0)
   /*{
              // initialize grid sites
              std::cout&lt;&lt;"GRID SIZE = "&lt;&lt;grid_size_&lt;&lt;std::endl;
              x_sites_ = new number_type[grid_size_];
              y_sites_ = new number_type[grid_size_];
              r_sites_ = new number_type[Nr_];
              R_ = grid_max_ - grid_step_;
              for (size_type i = 0; i &lt; grid_size_; ++i)
              {
                      x_sites_[i] = x_from_index(i);
                      y_sites_[i] = -y_from_index(i);
                      r_sites_[i] = R_ * i / Nr_;
  
              }
  
  
      }*/
  
      {}
      ~Collision(){}
  </code></pre>
  
  <p>I added empty brackets and deconstructor; This will not report heap memory issue. Perhaps an idea why the "x_sites, y_sites" are not cleaned up by the deconstructor?</p>