Скомпилированный в GCC exe файл вылетает досрочно?

Question

[Александр Попов]

Есть готовый проект на C, который абсолютно корректно работает в режиме отладки. Однако при запуске скомпилированного exe файла происходит очень странная вещь: программа вылетает как будто по таймеру. Дело в том, что если я ставлю в консоль отладочный вывод, то при разных запусках успевает вывестись разное количество строк.

Дело точно не в буфере: я добавлял в конец кода fflush(stdout), и ничего не изменилось. Дело вообще не в консольном выводе: в последнем тесте идёт создание файла и сверка содержимого с другим файлом, и до создания программа явно не доходит, файла в каталоге нет. Но в режиме отладки всё, как я уже писал выше, работает.

Код проекта можно посмотреть здесь.

Подскажите, пожалуйста, в чём моя ошибка.

Comments

[jcmvbkbc]

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

Как минимум в том, что код по ссылке не собирается.

Answer 1

[jcmvbkbc]

Но в режиме отладки всё, как я уже писал выше, работает.

Да не, это только видимость. Смотри:

$ gcc -std=c99 -O2 -g3 -fsanitize=address main.c acp.c md5.c -o main
$ ./main
Base64('Hello') = "SGVsbG8="
MD5('Hello') = "8b1a9953c4611296a827abf8c47804d7"
=================================================================
==1045705==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000000071 at pc 0x7fb0d46486f8 bp 0x7ffd0affb580 sp 0x7ffd0affad30
WRITE of size 33 at 0x604000000071 thread T0
    #0 0x7fb0d46486f7 in __interceptor_strcat ../../../../src/libsanitizer/asan/asan_interceptors.cpp:377
    #1 0x564b2388c0de in prepareKeys /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:263
    #2 0x564b2388cac4 in acraw /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:319
    #3 0x564b2388d8c2 in acraws /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:401
    #4 0x564b2388d8c2 in acraws_basic /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:409
    #5 0x564b2388a62e in testSimpleEncryption /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/main.c:20
    #6 0x564b2388a368 in main /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/main.c:111
    #7 0x7fb0d44461c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #8 0x7fb0d4446284 in __libc_start_main_impl ../csu/libc-start.c:360
    #9 0x564b2388a440 in _start (/home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/main+0x3440)

0x604000000071 is located 0 bytes to the right of 33-byte region [0x604000000050,0x604000000071)
allocated by thread T0 here:
    #0 0x7fb0d46b89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x564b2388fee7 in md5StringHash /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/md5.c:227

Comments

[Александр Попов]

И как это понимать? Я вообще на строке 263 у себя не вижу ничего такого, что могло бы вызвать проблему. Там символы по индексам заполняются, перед этим выделяется память под строку в корректном размере. Сейчас ещё раз перечитал построчно код - выглядит корректно.

[jcmvbkbc]

И как это понимать? Я вообще на строке 263 у себя не вижу ничего такого, что могло бы вызвать проблему.

Добавить в свою сборку -fsanitize=address и читать актуальный вывод.
Код по твоей ссылке не собирается -- я поправил его локально.

[Александр Попов]

jcmvbkbc, у меня собирается, но без этого флага. Я так понимаю, этот флаг обязателен, без него компилировать не принято? Почему в отладчике работает?

& 'c:\Users\Alex\.vscode\extensions\ms-vscode.cpptools-1.18.5-win32-x64\debugAdapters\bin\WindowsDebugLauncher.exe' '--stdin=Microsoft-MIEngine-In-jcy0pkn1.aoz' '--stdout=Microsoft-MIEngine-Out-hsfqfz5g.clb' '--stderr=Microsoft-MIEngine-Error-mnxcifzi.5or' '--pid=Microsoft-MIEngine-Pid-mxlmcoo1.oxa' '--dbgExe=E:\msys64\ucrt64\bin\gdb.exe' '--interpreter=mi'

Вот такой командой я запускаю отладку. Точнее, запускаю я её кнопкой, VS Code за меня её запускает.

[Александр Попов]

jcmvbkbc, видимо, то, что я вижу в режиме отладки - это работа некого интерпретатора, исполняющего мой код построчно, я прав? Но с памятью он реальной работает, верно? Если у меня при ошибках с адресами данные перетирались.

[Александр Попов]

E:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lasan: No such file or directory
collect2.exe: error: ld returned 1 exit status

Вот такое пишет

[jcmvbkbc]

у меня собирается

У тебя в Makefile написано:

all:$(CPP_EXECUTABLE)
CPP_EXECUTABLE :=$(CPP_SOURCES:.cpp=)
CPP_SOURCES :=$(wildcard *.cpp)

при этом нет ни одного файла *.cpp, я очень хотел бы узнать, как оно у тебя собирается.

Кроме того, ты используешь функцию itoa, но это нестандартная функция, в стандартную библиотеку C она не входит.

[jcmvbkbc]

видимо, то, что я вижу в режиме отладки - это работа некого интерпретатора, исполняющего мой код построчно, я прав?

Александр Попов, нет. Ты видишь работу реально откомпилированного кода но под управлением отладчика.

[Александр Попов]

jcmvbkbc,

Кроме того, ты используешь функцию itoa, но это нестандартная функция, в стандартную библиотеку C она не входит.

Я в интернете нашёл это решение. Чем-то адекватным его можно заменить, или нужно писать свою реализацию?

при этом нет ни одного файла *.cpp, я очень хотел бы узнать, как оно у тебя собирается

Я говорил о том, что после прохода отладчиком в папке остаётся exe файл. Это не считается? Он ведь в любом случае генерируется компилятором. Make файл этот я в данный момент по сути не использую, надо сделать нормальный и начать использовать, просто руки пока не дошли. Мне бы с кодом разобраться

[jcmvbkbc]

Вот здесь ты выделяешь 33 байта для строки: https://github.com/popov654/alphacrypt2/blob/maste...
А вот здесь ты в тот же буфер добавляешь ещё один хеш: https://github.com/popov654/alphacrypt2/blob/maste...
strcat не меняет размер выделенной для строки памяти, это нужно делать самостоятельно перед её вызовом.

[Александр Попов]

jcmvbkbc,

я очень хотел бы узнать, как оно у тебя собирается

gcc main.c acp.c md5.c -o main

Например так. Да, ламерский подход, но в учебнике для начинающих по C++ рекомендуют именно так и компилировать решения, только через g++. Если бы в коде было что-то совсем плохое, код бы вообще не скомпилировался - а тут он компилируется. И в режиме отладки даже идеально отрабатывает.

[jcmvbkbc]

Я говорил о том, что после прохода отладчиком в папке остаётся exe файл.

Александр Попов, ты предлагаешь отлаживать файл который остаётся у тебя в папке, или ты выложил исходники для того, чтобы желающие могли собрать его сами? Я надеюсь, что второе, но см. выше, сборка просто так не работает.

Например так. Да, ламерский подход

Подход как подход. Но это не тот код, который ты выложил.

[jcmvbkbc]

Я в интернете нашёл это решение. Чем-то адекватным его можно заменить, или нужно писать свою реализацию?

Я заменил его на это:

static char *itoa(int v, char *str, int base)
{           
        sprintf(str, "%d", v);
        return str;
}

[Александр Попов]

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

[jcmvbkbc]

каким образом оно тогда не падало при отладке?

UB он такой.

[Александр Попов]

jcmvbkbc, большое спасибо за помощь, сейчас проект нормально отрабатывает и в отладчике, и напрямую. Кроме того, я поправил Makefile, теперь можно собирать через make.

C:\Users\Alex\Documents\cpp\alphacrypt>acp.exe -i """Hello world!""" -k mysecretpass
s3Q3f5crD7zwY#25484#5

Answer 2

[Wataru]

Звучит в точности как симптомы Undefined Behavior. На самом деле программа вылетает из-за, например, доступа к неправильным указателям. Но во время отладки звезды выстраиваются так, что это некорректное действие не приводит к падению программы.

Добавляйте больше отладочного вывода во всех функциях и между всеми важными кусками кода, например на каждой итерации цикла. Выводите разные строки везде, а в циклах еще и переменные цикла вставляйте.
Выводите в stderr.

Потом смотрите, какую строчку программа вывела последней. Вот от этого вывода в исходнике и до следующего вниз по коду где-то и происходит ошибка. Вот уже проделав эту работу возвращайтесь сюда - на конкретный кусок кода я могу внимательнее посмотреть.

Возможно, там где-то выход за границы массива, Попробуйте еще, например, увеличить все выделенные строчки и массивы в коде раз в 10. Если после этого программа отработает, ищите, где у вас ошибка в логике - почему массивов не хватает.

Comments

[Александр Попов]

Я не понимаю, почему при добавлении отладочного вывода он постоянно обрывается на разных моментах? Как в таких условиях ловить ошибку?

[Wataru]

Александр Попов, значит, программа может упасть в разных местах. Посмотрите на один результат запуска - смотрите, какой кусок кода падает?

И да, если вы не в stderr пишите, то из-за буферизации часть вывода может теряться при падении.

[Александр Попов]

например на каждой итерации цикла.

Я так и сделал в функции, генерирующей ключи (мне кажется, падение происходит в ней). И она отрабатывает минимум (максимум?) два раза из требуемых семи, судя по максимальному количеству строк в выводе, которое я вижу.
Есть ещё функции кэширования и чтения из структуры кэша ключей, в которых я не вполне уверен, но я полностью закомментировал их использование, и ошибка не пропала.

[Александр Попов]

Wataru, спасибо. Поменял вывод в той функции на вывод в stderr, но в плане поведения вообще ничего не изменилось.

[Александр Попов]

Как я понял, падение происходит где-то внутри acraw(), возможно, внутри prepareKeys(). До выделения кода генерации ключей в отдельную функцию оно точно так же падало, кстати.

[res2001]

Александр Попов, Добавлю немного.
Используйте assert везде где возможно для проверки предусловий и может быть постусловий в функциях. Хорошо расставленные ассерты сильно облегчают поиск ошибок.
Например есть смысл в каждой функции проверять корректность полученных параметров.
assert используется только в отладочной версии, в релизной версии ассерты не нужны, поэтому они не будут влиять на производительность и т.п. Ассерты отключаются добавлением опции компилятору -DNDEBUG.
https://en.cppreference.com/w/c/error/assert

[Wataru]

Александр Попов, Вот и ошибка:

char* ck_str = (char*)malloc(strlen(k));
 strcpy(ck_str, k);

strlen - выдает количество символов в строке. Но памяти для строки надо на 1 байт больше - ведь есть же еще завершающий '\0'. Так что вот эта вот strcpy пишет 0 за границу массива.

[Wataru]

Александр Попов, Еще, у вас там полно работы с указателями вроде char* original_key = ck_str;. Не надо так делать. Зачем вы этот псевдоним ввели? Он указывает на все ту же память, что и ck_str. Но дальше в коде используете то ck_str, то original_key. Хорошо еще, что хоть не free() их обе.

[Александр Попов]

Wataru, ck_str по ходу алгоритма постоянно обновляется (там идёт присвоение нового адреса указателю), а original_key - нет. Так что это точно не ошибка. Хотя может быть, реализовано коряво.

[Александр Попов]

Wataru, спасибо, я почему-то думал, что это не важно, поскольку дальше пустой участок памяти, и там всё равно нули. Но как оказалось, так бывает не всегда

[Александр Попов]

Wataru, только вот падает не поэтому. Я исправил это место, и ничего не изменилось, опять же. Больше того, я поправил все аналогичные места в коде...

[Wataru]

Александр Попов, Добавляйте еще более частый отладочный вывод, говорите, между какими строчками в какой функции падает.

[Александр Попов]

Wataru, заменил вызов prepareKeys() на следующий код:

for (int i = 0; i < 7; i++) {
    keys[i] = (char*) malloc(128);
    for (int j = 0; j < 128; j++) keys[i][j] = 48;
}

Падать перестало. Так что ошибка явно там, внутри.

[Wataru]

Александр Попов, Добавляйте кучу отладочного вывода. Там все сложно, сплошные char* туда-сюда летают. Так что много мест, где можно допустить ошибку. Плюс что за hashfn там используется-то?

[Александр Попов]

Wataru, это просто указатель типа void* на функцию md5StringHash. Нужно для того, чтобы потенциально в будущем можно было подменять хэш-функцию на другие.

Кстати, я наконец догадался, что не так. У меня в отладочном режиме тоже постоянно падало на этой совершенно безобидной строчке несколько дней назад, но после каких-то рандомных изменений в коде в других местах это падение само ушло, и я подумал, что навсегда...

char* output = (char*) malloc(33);

md5.c, строка 227. Не понимаю, что ему не нравится - обычный вызов. Не потому ли, что во внешней функции вызывается эта функция подряд два раза от разных строк, компилятор пытается генерировать параллельный код, использующий два потока, и это каким-то образом ведёт к ошибке?

[Wataru]

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

Что там с выводом-то? Между каких строк падает?

[Wataru]

Александр Попов, Продублирую, а то забыл вас по нику назвать:
malloc может падать, если вы до этого память уже испортили выходами за границу массива.

Что там с выводом-то? Между каких строк падает?

[Александр Попов]

Wataru, у меня там нет массивов в чистом виде, всё динамическое. Исключение - массив key_cache, у которого лимит 128, но он и близко не заполняется настолько.

Пока не понимаю, пытался убирать вызовы md5StringHash - он даёт segfault в начале других функций, например, strreverse. Всё как вы и сказали, это последствия, а где причина - пока не очень ясно. Я наверное обновлю код в репозитории, чтобы было видно, что поправлено.

[Александр Попов]

Wataru, вы же сами выше написали, что то, где он падает (где segfault в отладчике высветило) - это мало о чём говорит, потому что память была раньше побита. А так - между строк 254 и 290 проблема проявляет себя, когда уже получен сегфолт.

[Wataru]

Александр Попов, Выход за границу массива = выход за границу строки, ведь строка - это тоже массив. Особенно опасно, когда эти массивы динамические.

[Wataru]

Wataru, Видя, где оно падает, есть шанс понять, с какой памятью проблема и оттуда размотать, а кто ее испоганил.

[Wataru]

Александр Попов, опять не туда ответил:
Видя, где оно падает, есть шанс понять, с какой памятью проблема и оттуда размотать, а кто ее испоганил.

[Александр Попов]

Wataru, простите, а как вообще можно испоганить настолько? ОС следит сама за целостностью кучи, так что ли?
Я просто в режиме отладки один раз неаккуратной операцией разыменования указателя с инкрементом (пытался сделать из char-а строку в один символ) изменил значение локальной int переменной, которая хранилась по соседству. Код начал работать неправильно, но сегфолта не было.

[Александр Попов]

Wataru, отписал выше, acp.c, строки 254-290.

[Александр Попов]

Wataru, со строками я вроде поправил размер выделяемой памяти везде (если только не проглядел ничего).

А вообще, там, где у меня были прямо крупные ошибки с размером в malloc() (выделялось в разы или на порядок меньше, чем надо), я это видел в режиме отладки прекрасно вчера-позавчера. Даже не в виде сегфолтов, а просто затирались одни данные другими, я это при просмотре массивов наблюдать мог.

А тут какая-то странная ерунда - в debug режиме всё работает, в нормальном - падает без сообщений в системный журнал или ещё куда-то... Интересно, кстати, можно ли настроить, чтобы реально ОС регистрировала такое падение.

[Wataru]

Александр Попов,

строки 254-290.

hashfc func точно не падает? если ее заглушкой заменить - падает?

Еще, попробуйте заменить 128 на 129 в malloc. Вы там какую-то строку засовываете в key в итоге. Какого размера возвращается буфер из func?

[Дмитрий]

Александр Попов, мд5 обычно 32 длиной

[Александр Попов]

Wataru, md5StringHash возвращает строку длиной 32 символа - или 33 байта. В malloc() там передаётся именно 33.

Заменил на заглушку (return "123456"), стало падать в других местах.

[Александр Попов]

Дмитрий, так и есть, но в конце '\0' символ же ещё. Это строка именно

[Александр Попов]

Wataru, "Вы там какую-то строку засовываете в key в итоге" - в keys[i] засовывается массив unsigned char, то есть именно байты, не символы. Распечатать это содержимое не получится, только в виде целых чисел в цикле. Там не требуется нуль-терминатор, поскольку максимальный размер массива фиксирован в 128 байтов (однако фактический - меньше, но после чтения хвост не будет использоваться, за это отвечает специальная переменная, уникальная для каждой итерации кодирования исходного текста). ck_str - это строковое представление того же самого ключа, на его основе делается ключ для следующей итерации.

[Александр Попов]

Wataru, я сейчас поменял строки с 225 по 228 на следующий код:

key_cache[i].strong_value[round * 2] = (char*) calloc(128, 1);
memcpy(key_cache[i].strong_value[round * 2], value[0], strlen(value[1]));
key_cache[i].strong_value[round * 2 + 1] = (char*) malloc(strlen(value[1])+1);
strcpy(key_cache[i].strong_value[round * 2 + 1], value[1]);

Я подумал, проблема может быть в том, что у меня в key_cache[i].strong_value[round * 2] копируются лишние данные (по сути так оно и было). Поэтому я заменил malloc() на функцию, которая инициализирует память нулями, и поменял последний аргумент в memcpy() на фактический размер реальных данных. Но, опять же, это ничего не дало.

[Александр Попов]

Wataru, оказалось, что косяк был в неверном использовании strcpy().

Answer 3

[CityCat4]

Отключи оптимизацию при сборке ключом -O0. В режиме оптимизации GCC вполне способен сам скрячить undefined behavior оптимизацией "неправильно" расположенных переменных, например.

Comments

[Александр Попов]

Оказалось, что дело было в strcpy() и моём неправильном понимании её работы. Вот что значит всю жизнь на PHP и JS кодить, потом такие вещи вообще кажутся не очевидными.

[CityCat4]

Александр Попов, Да, С такая штука - в ней запросто выстрелить себе в ногу. Ошибка при работе с памятью - самая распространенная, strcpy() запросто перепишет чужую память, почему и стараются по возможности strncpy() использовать :)