Участвуйте в конкурсе глупых и страшных ошибок на языке C++

Самая страшная ошибка - на нем писать.

Позавчера пытался запустить ваш pvs-studio на фрибзд через слой совместимости с линуксом и портированный strace. Медаль дадите?

когда было нечем заняться,… папа карло строгал буратин.

Шутка

Угу, прослыть в inet дураком N1 весьма почётно.

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

int* p1, p2;

2. некоторым кажется, что они так а инкрементят

int a = 1;
int* p = &a;

...

*p++;

Медаль дадите?

Я не PVS, но на их месте не дал бы. Потому что «пытался» - этого не достаточно. Вот если бы «успешно запустил», тогда другое дело.

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

Смысл в том чтобы фрибздшную сборку подцепить и проанализировать.

А есть софт для поиска ошибок в ДНК?

тогда это уже не просто «пытался»

Медаль дадите?

Да. Куда отправлять? :)

Они внешне заметны без софта

Не скажите, коллега. Рецессивная аллель влияет на фенотип, только когда генотип гомозиготен.

Мне кажется, такие ошибки в реале даже джуны не допускают)

Даже не знаю, что можно считать «глупой и страшной» ошибкой.

Ошибки по большей части банальны - ошибки копипаста, когда в однотипном наборе присваиваний забыли поменять одну из переменных, ошибки в сравнениях, когда вместо =< стоит < или наоборот, ошибки смещения на 1, перепутанные единицы измерения, когда метры с футами в одном вычислении фигурируют и т.п. А вот последствия ошибок порой бывают действительно и глупые, и страшные.

У меня сейчас в рабочем списке фигурирует на исправление еще одна типичная ошибка многопоточного приложения:

• Поток А запускает поток Б.
• Поток Б ставит в очередь коллбек, который должен быть исполнен в потоке А.
• Поток А до обработки коллбека завершает работу потока Б и освобождает общие ресурсы.
• Срабатывает коллбек, и программа обращается к освобождённой памяти.

Мне кажется, такие ошибки в реале даже джуны не допускают)

в этом-то и проблема )

все такие профессионалы, ух, с кучей набитых шишек, аж вся голова буграми пошла, а потом по три часа вместе и по очереди по коду ползают, чтобы в итоге поймать какое-нибудь смешное if(a=b)

(*p)++

Вот это сильно меня удивило.

Это вообще законно? Провал выполнения в нижележащую «мёртвую» функцию

В случае с C там был бы просто UB при попытке прочитать возвратное значение, в случае с C++ там двойное UB и ноги превращённые в кашу, а выполнение кода ушло в мёртвую функцию, которая вообще нигде не вызывалась.

Я как-то долго пытался понять, что не так с кодом, который работает на более новых компиляторах, но на gcc 4.x.x (сколько-то там, не помню точную версию) валит программу абсолютно без видимой причины. Дело под 32-битной системой было.

Код был приблизительно такой, схематически изображаю:

static int foo_real_impl(int* a, int* b, int c, int d /* тут на самом деле несколько разных типов, включая указатели на разные структуры */)
{
  /* тут куча логики с вызовами разных функции,
     которые вызывают еще кучу функций.
     довольно глубокий уровень вложенности вызовов на стеке.

     И где-то в глубине этого кода программа падала из-за обращения по битому указателю.
  */
}

int foo(int* a, int* b, int d)
{
  return foo_real_impl(a, b, 0, d); 
}

Так вот когда я пытался анализировать стек после падения, там были видны функции которые были глубже, чем foo(), и также были видны те, который ближе к верхушке стека, чем foo(). А самой foo() не было.

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

В общем, я был вообще не уверен, что раскрутка стека отображается верно. Или может сам стек уже битый в момент падения.

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

В итоге пришел к тому, что что-то не так с кодом foo(), потому что именно она портит аргументы. Дизассемблировал функцию и обнаружил что да - что-то не так.

Компилятор, видя что, что foo_real_impl() - это static, решил присвоить ей соглашение о вызове fastcall и передать часть аргументов в регистрах. Далее при генерации кода для foo() он применяет оптимизацию, аналогичную хвостовой рекурсии, когда он не вызывает вложенную функцию, а замещает ею текущую функцию на стеке.

Поэтому foo() на стеке и не видна была.

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

В общем, на ошибку в компиляторе наткнулся.

Вчера наткнулся. Обработка ошибки. log_error — местная макромагия (к ней претензий нет), здесь выдавшая мне в лог вместо сообщения полный путь к какому-то хедеру.

std::ostringstream ss;
ss << "bla-bla-bla in [" << x << ", " << y + "]";
log_error(ss.str());

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

 #define NUICODE

Самая глупая и страшная ошибка это C++ сам по себе в принципе

Медаль дадите?

Да. Куда отправлять? :)

Дай лучше ему сырцы, пусть нативный порт на FreeBSD сделает.

В случае с C там был бы просто UB при попытке прочитать возвратное значение, в случае с C++ там двойное UB и ноги превращённые в кашу, а выполнение кода ушло в мёртвую функцию, которая вообще нигде не вызывалась.

А что не так? При UB компилятор не даёт никаких гарантий на поведение бинарника. Вот тебе полная лажа и выдалась.

А что не так?

То, что в GCC это предупреждение (в старых GCC предупреждения в дефолте не было вообще), а не явная ошибка как, к примеру, в MSVC.

А что не так?

То, что в GCC это предупреждение (в старых GCC предупреждения в дефолте не было вообще), а не явная ошибка как, к примеру, в MSVC.

Разыменование NULL – это тоже в лучшем случае предупреждение. А зачастую даже близко нет. Ичо?

Мой однокурсник в своё время придумал исключительную ситуацию:

SUCCESSFULL division by zero!

Вселенная схлапывается автоматически?

Видимо, да :)

Двухтысячная венда любила с тревожным блямканьем вывалить messagebox с красной пиктограммой ошибки и текстом «operation completed successfully».

А ты знаешь, почему? Эту ситуацию, кстати, пивас студия могла бы ловить.

Не знаю.

Фугкции Win32 api обычно возвращают не код ошибки, а -1 замаскированный под дефайн, например INVALID_HANDLE. Чтобы узнать код ошибки, надо позвать GetLastError(), что-то вроде errno (которая тоже функция на самом деле). Чтобы вывести диалог с сообщением об ошибке надо ещё парочку Win32 фунций позвать, которые, закончившись успешно переписывают код ошибки, и GetLastError() уже возвращает success. Если первым делом не сохранить результат GetLastError(), он будет переписан, что и приводит к таким комическим messageboxам.

Как бы не ругали С++ но ничего лучше не придумали.

Орден сутулого. Держи.

Вообщем заработало, внезапно оказалось что «все не так как на самом деле»:

To generate 'compile_commands.json, add one flag to the CMake call:
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On .

Вам бы надо как-то ярче описать что генерировать список команд сборки надо из самой системы сборки. А то мальчик Саша узнал что cmake такое умеет делать только в 40 лет например. Поэтому полез сразу отладчиком изучать почему ‘trace’ не работает, последовательно пройдя все приключения с /compat/linux, историю strace/truss и rfork.

Попробую еще из остальных BSD запустить теперь.

Опитмизровал вычислительно тяжёлый кусок, решил поиспользовать std::minmax.

single_calc - лёгкая однострочная функция, она везде инлайнилас

Старый код (работал)

void heavy_calc(int a, int b){
  int min_sum = 0;
  int max_sum = 0;
  for (int i =0; i < 100000; ++i)
  {
    int sa = single_calc(a, i);
    int sb = single_calc(b, i);
    int s_min = std::min(sa, sb); 
    int s_max = std::min(sa, sb); 
    min_sum += s_min;
    max_sum += s_max;
  }
  //что-то делаем с min_sum и max_sum
}

Новый код (на части платформ работал, но через месяц при релизном тестировании на малоподдерживаемой платформе откуда-то взялись некорректные результаты)

void heavy_calc(int a, int b){
  int min_sum = 0;
  int max_sum = 0;
  for (int i =0; i < 100000; ++i)
  {
    int sa = single_calc(a, i);
    int sb = single_calc(b, i);
    auto min_max = std::minmax(sa, sb);
    min_sum += min_max.first;
    max_sum += min_max.second;
  }
  //что-то делаем с min_sum и max_sum
}

Бисекция была невозможна, поскольку из-за слабого CI код промежуточный между релизами не компилирвался под минорную платофрму. Был проведён анализ метоодом добавления логов и сравнения их на идентисчночть между платформами и спустя неделю анализа стало ясно что входные данные этой функции - нормальные, а вычисляемые min_sum и max_sum - уже ненормаьлные.

Любая попытка вставить отладочное логгирование внутрь цикла загадочно исправляло проблему.

В результате я 2дня искал багу в 5 строчках внутри цикла (время теста, проявляющего проблему - было порядка 1 часа, попытка тестировать функцию отдельно от комплекса ПО - также исправляла проблему)

Причина под псевдоспойлером

V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
auto min_max - это пара ссылок, а не пара int-ов. И она теряла валидность к моменту её использования. 

Зачем материшься уважаемый, да?

Компиляторы разные были?

Участвуйте в конкурсе глупых и страшных ошибок на языке C++

Выглядит как предложение начать писать на C++.

unwrap().unwrap() забыли поставить после точки

unwrap unwrap пейшу чрез строчку я

ведь если я свинья

то педантичная

UBи нигде я встретить не хочу

я лучше за процессорную мощность приплачу

да, тот на котором воспроизводилось и на котором нет - были и компиляторы разные, и архитектуры CPU разные.

Заменили auto min_max на std::pair<int, int> min_max и все заработало как надо?

да, что-то подобное (не уверен что скопилировалиось именно так, давно это было).

Скорее всего в обоих компиляторах auto выводилось как std::pair<int&, int&> но некоторые варианты кодогенерации затирали временные int, а другие варивнты - нет

самая страшная ошибка времени исполнения - это маленький стек

нет предела человечской, железячник программирует

void get_pcie_addr(char *device_name, char *pcie)
{
  int i=0;
  FILE *cmd_fp;
  char *ptr = NULL;
  char cmd[256] = {0};
  char cmd_ret[64] = {0};
  
  if(!device_name)
  {
    return ;
  }
  ptr = device_name + 5;
  snprintf(cmd, sizeof(cmd) - 1, "udevadm info -q path -n %s | perl -nle'print $& "
           "while m{(?<=/)[0-9a-f]{4}:[0-9a-f]{2}:[0-9a-f]{2}\\.[0-9a-f]}g' | tail -n 1",ptr);
  cmd_fp = popen(cmd, "r");
...

У меня был маленький стек и я этого стеснялся.

здесь есть мои почитатели ;)

У вас точка отклеилась.

У меня был маленький стек и я этого стеснялся.

А почему в прошлом? Потом увеличил?

Да, без регистрации и СМС. Надо лишь …