Здравствуйте, Pzz, Вы писали:

_>>Всё так, и пререзапускается у нас автоматом. Но была ситуация — при вычитке, разборе, и дальнейшей обработке сообщения из кафки срабатывал неверный ассёрт, ну так вот вышло, моя лажа. И программа падала, не закоммитив это сообщение. А потом поднималась — и вычитывала его опять...

Pzz>А если бы там по делу был assert? А программа не падала бы, а продолжала жить инвалидом?
Выбор сложный, мы решили вот так, урон меньше. Хотя мне тоже нравится, когда падает с корой.

Pzz>Похоже, в плане Б не хватает действия на случай, если программа падает без какого-либо прогресса.
Да, что? Как после смерти программы чем-то внешним понять почему в общем случае она вперёд не двигается?

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

_>>Такого требования, чтобы библиотеки пересобирать, нет. Могут быть сложности, если память выделяетя в библиотеке, а освобождается в прикладном коде, но это само по себе нездорово. У меня библиотеки собираются без ASAN, продукт с ним, и никаких спецэффектов не наблюдал.
Pzz>А мне питонщики сказали, что есть. Кто из вас неправ?
Это memsan всё-таки, а не asan, там таки есть требование пересобирать всё.
Для ASAN тоже желательно пересобирать всё, но требования такого нет, насколько я в курсе, и я на протяжении многих лет на текущем проекте ни разу не столкнулся с проблемами, связанные с тем, что внешние зависимости собираются без ASAN (и вообще релиз), а мой код — с ним. Библиотек немного, до 10-ти. Часть C, часть C++. Header-only я не считаю, конечно.
Могу предположить, что в MSVC будет всё хуже, там debug/release CRT плохо уживается и без ASAN.

Здравствуйте, Pzz, Вы писали:

_>>Всё так, и пререзапускается у нас автоматом. Но была ситуация — при вычитке, разборе, и дальнейшей обработке сообщения из кафки срабатывал неверный ассёрт, ну так вот вышло, моя лажа. И программа падала, не закоммитив это сообщение. А потом поднималась — и вычитывала его опять...

Pzz>А если бы там по делу был assert? А программа не падала бы, а продолжала жить инвалидом?
Выбор сложный, мы решили вот так, урон меньше. Хотя мне тоже нравится, когда падает с корой.

Pzz>Похоже, в плане Б не хватает действия на случай, если программа падает без какого-либо прогресса.
Да, и что? Как после смерти программы чем-то внешним понять почему в общем случае она вперёд не двигается?

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

_>>Такого требования, чтобы библиотеки пересобирать, нет. Могут быть сложности, если память выделяетя в библиотеке, а освобождается в прикладном коде, но это само по себе нездорово. У меня библиотеки собираются без ASAN, продукт с ним, и никаких спецэффектов не наблюдал.
Pzz>А мне питонщики сказали, что есть. Кто из вас неправ?
Это memsan всё-таки, а не asan, там таки есть требование пересобирать всё.
Для ASAN тоже желательно пересобирать всё, но требования такого нет, насколько я в курсе, и я на протяжении многих лет на текущем проекте ни разу не столкнулся с проблемами, связанные с тем, что внешние зависимости собираются без ASAN (и вообще релиз), а мой код — с ним. Библиотек немного, до 10-ти. Часть C, часть C++. Header-only я не считаю, конечно.
Могу предположить, что в MSVC будет всё хуже, там debug/release CRT плохо уживается и без ASAN.