Тот же код работает с Ma c Clang, но вылетает с Unix GCC

Question

У меня странная проблема с кодом, который я запускаю; Сложность в том, что он не мой, а довольно большой код с различными функциями и заголовками,

быстрый факт

1.) Работает на моем компиляторе машины Ma c: Apple clang версия 11.0 .0

2.) Сбои на моем Unix компьютере с g cc 6.3.0 или выше

---

Отладка:

При использовании инструмента gdb cra sh происходит по простой строке std :: string line = ""; С ошибкой: «report free (): неверный следующий размер (нормальный): ... ;»

---

Как я уже сказал, код огромен, но позвольте мне попытаться дать некоторые специфика. Это происходит в функции

void read_data(std::string filename, number_type & impact_parameter, number_type &    n_participants, number_type & 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...

Файлы, которые читаются, имеют формат:

# event 0
# b     = 10.63639744
# npart = 95
and so on...

Он будет читать через вторую строку current = 10.63639744, а затем, переходя на следующую строку, вылетает,

*** Error in `./MultB': free(): invalid next size (normal): 0x0000000001fb9760 ***

Буду очень признателен за помощь в этом. Это проблема компилятора (Macchiato vs Unix) или что-то с этим можно сделать,

спасибо, Дамир

--------------- Обновление -------------------

Кажется, GDB не очень помог найти ошибку памяти в коде; Я разделил код на то, какая часть кода будет работать.

Опять же, не имея возможности опубликовать полный код (состоящий из множества заголовков и функций), кажется, что код фактически не будет иметь «проблемы с кучей», если в основном классе я отклоняю инициализацию некоторых переменных-членов / * stuff * /,

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<<"GRID SIZE = "<<grid_size_<<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 < grid_size_; ++i)
            {
                    x_sites_[i] = x_from_index(i);
                    y_sites_[i] = -y_from_index(i);
                    r_sites_[i] = R_ * i / Nr_;

            }


    }*/

    {}
    ~Collision(){}

Я добавил пустые скобки и деконструктор; Это не сообщит о проблеме с кучей памяти. Возможно, идея, почему «x_sites, y_sites» не очищены деконструктором?

Answer 1

Нашел решение, @Marek R был прав на деньги. Включение команды -fsanitize = address при компиляции кода определяет, где именно происходит переполнение кучи-буфера. Вот фрагмент вывода,

SUMMARY: AddressSanitizer: heap-buffer-overflow auxiliary/collision.hpp:84 in Collision<double>::Collision(double, double)

Затем, глядя на класс столкновений, который я разместил в вопросе,

        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 < grid_size_; ++i)
        {
                x_sites_[i] = x_from_index(i);
                y_sites_[i] = -y_from_index(i);
                r_sites_[i] = R_ * i / Nr_; // line 84
        }

Проще говоря, динамический массив "r_sites_" имеет меньший размер ( N_r) затем "x (y) sites " (grid_size_), даже если они находятся в тех же самых выражениях l oop,

, Damir

Answer 2

, так как ваш код не воспроизводит проблему, и строка, в которой он сообщает о сбое, почти не может быть сбой ... есть несколько вещей, на которые стоит обратить внимание:

1) у вас есть прототип, отличный от объявления?

Много раз, когда у вас есть cra sh, который не может быть возможен, потому что вызывающий код и вызываемый код имеют разные ожидания относительно того, какие элементы были заложены в преамбуле к вызову.

, например:

`int func(long long param, int param2)`

и

`int func(double param, int param2)`

начнутся с другим смещением и ожидают, что локальная переменная будет иметь другое смещение, так что если один находится в .h, а другой в. cpp, тогда произойдут плохие вещи.

2) std::ifstream infile(filename); каким-то образом скрывается.