Зная, где происходит ошибка сегментации при сравнении двух файлов

У меня есть следующая структура:

int main(int argc, char **argv) {
     try {
        FX3USBConnection fx3USB3Connection = FX3USB3Connection();
        fx3USB3Connection.send_text_file();
    }
    catch (ErrorOpeningLib& e) {
        printf("Error opening library\n");
        return -1;
    }
    catch (NoDeviceFound& e) {
        printf("No device found\n");
        return 0;
    }

    return 0;
}

Последнее, что я делаю в send_text_files, — это сравниваю два txt-файла следующим образом:

printf("Loopback recieved, checking if I received the same that I sended\n");
files_match(out_text_filename, in_text_filename);
printf("Exited without problem");
return; // (actually implicit)

Я уже использовал 2 версии функции files_match, но последняя является точной копией этого Сравните два файла

bool FX3USB3Connection::files_match(const std::string &p1, const std::string &p2) {
    bool files_match;
    std::ifstream f1(p1, std::ifstream::binary|std::ifstream::ate);
    std::ifstream f2(p2, std::ifstream::binary|std::ifstream::ate);

    if (f1.fail() || f2.fail()) {
        return false; //file problem
    }

    if (f1.tellg() != f2.tellg()) {
        return false; //size mismatch
    }

    //seek back to beginning and use std::equal to compare contents
    f1.seekg(0, std::ifstream::beg);
    f2.seekg(0, std::ifstream::beg);
    files_match = std::equal(std::istreambuf_iterator<char>(f1.rdbuf()),
                      std::istreambuf_iterator<char>(),
                      std::istreambuf_iterator<char>(f2.rdbuf()));
    f1.close();
    f2.close();
    if (files_match) { printf("Files match\n"); }
    else { printf("Files not equal\n"); }
    return files_match;
}

Иногда я получаю ошибку, а иногда нет. Когда я получаю сообщение об ошибке, я получаю:

Loopback recieved, checking if I received the same that I sended
Files match

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

Итак, печать после вызова files_match не печатается, поэтому я предполагаю, что проблема была в функции. Однако я делаю печать непосредственно перед оператором возврата, и она печатается правильно.

PS: Я прокомментировал функцию files_match и у меня нет проблем.

PS1: Файлы могут иметь что-то вроде этого символа: ¥


person Agustin Barrachina    schedule 13.02.2019    source источник
comment
Используйте отладчик.   -  person eerorika    schedule 13.02.2019
comment
Не связано, не то, чтобы это имело значение, но называть переменную так же, как функцию, — это рецепт путаницы. Просто говорю.   -  person WhozCraig    schedule 13.02.2019
comment
«Итак, печать после вызова files_match не печатается, поэтому я предполагаю, что проблема была внутри функции». Нет, это не обязательно правильно, потому что ввод-вывод буферизируется и не появляется сразу. Если вы хотите, чтобы printf отображалось сразу, вы должны следовать за ним с fflush(stdout);. Или просто используйте отладчик, как уже предлагалось.   -  person john    schedule 13.02.2019
comment
^^^^ или: printf("Exited without problem\n"); ‹=== обратите внимание на новую строку.   -  person WhozCraig    schedule 13.02.2019
comment
Новая строка часто приводит к сбросу печати на stdout, но это не гарантируется, лучший способ — добавить fflush(stdout);   -  person john    schedule 13.02.2019
comment
Мне кажется, что наиболее вероятным объяснением является то, что ваша ошибка возникает вскоре после возврата files_match и files_match не является причиной ваших проблем (мне кажется, что это нормально). Вывод printf не появляется из-за проблем с буферизацией, описанных выше.   -  person john    schedule 13.02.2019


Ответы (1)


Да, как предложил @john, мне пришлось добавить функцию fflush(). Там я понимаю, что ошибка на самом деле была за пределами всего этого цикла, но на самом деле это происходит при выходе из раздела try{}. Мне кажется, что не удается уничтожить файл fx3USBConnection.

Спасибо! Теперь я был так введен в заблуждение, зная, что fprint на самом деле буферизован.

person Agustin Barrachina    schedule 13.02.2019