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

jcmvbkbc,

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

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

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

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

jcmvbkbc,

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

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

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

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

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

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

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

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

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

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

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 за меня её запускает.

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

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

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

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() на фактический размер реальных данных. Но, опять же, это ничего не дало.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;
}

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

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

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

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

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

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

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