Re: [devel] [bugzilla-daemon@altlinux.ru: [Bug 34347] Странный временный нуль-маршрут ломает сетевую rootfs]

[Leonid Krivoshein <klark.devel@gmail.com>]

11.06.2018 13:11, Arseny Maslennikov пишет:
> On Wed, May 30, 2018 at 04:34:23AM +0300, Leonid Krivoshein wrote:
>> 28.05.2018 19:19, Arseny Maslennikov пишет:
>>> Пользуясь случаем, всё-таки прошу одобрить таск 206842, исправляющий
>>> баги 34347 и 34320. Если код слишком плохой даже для пропагатора,
>>> я поправлю, мне не жалко. :)
>> Видимо я не спец в нулевых маршрутах, поэтому мало чем могу быть полезен. :)
>> Но строчка assert((sz - sp) == 1); вызвала спортивный интерес: как поведёт
>> себя приложение с PID=1, если утверждение окажется ложным, с учётом того,
>> что в опциях сборки нет NDEBUG.
> Как и любое другое, завершится со всеми вытекающими последствиями (я
> этим вопросом тоже задался, когда готовил исправление).
>
> С другой стороны, код, в котором такое утверждение под assert() ложно,
> содержит логическую ошибку и должен быть исправлен до попадания в сизиф.
> Именно так его применяют, например, в (извините) systemd — деймон, который
> падает со скрипом, да ещё сообщает место, куда смотреть, лучше, чем
> "работающий" деймон с утекающей памятью, или такой, который просто
> продолжает творить некоторую известную глупость, в то время как разработчик
> не знает горя. Да, даже если это PID 1, в таком случае — тем более.

Разница между демоном, который крутится в stage2 месяцами, и инитом с 
PID=1 в initramfs/stage1 очевидна. Для демона утечки памяти -- "мина 
замедленного действия", пропагатор же ими весь напичкан (был?). И 
ничего: всё "прощается" и забывается при переходе в stage2. Если же 
упадёт инит, в журнал уже ничего не попадёт: последнее, что мы увидим в 
консоли -- хвост от паники ядра. Мы даже не поймём, что случилось и почему.


> assert() в нашем случае упрощает тестирование: увидя, что "система
> загрузилась" (пропагатор сделал всё необходимое), мы точно знаем, что
> определённой глупости не будет, вместо того, чтобы на это надеяться.

Проверялись длины строк (адреса), зависящие от конкретной машины. В этой 
ситуации assert() слишком жестковат в качестве средства отладки. 
Поскольку надеяться можно будет на вашей машине, но так ли это будет на 
других?..


>> Один не закомментированный assert() в init.c
>> есть, это будет второй.
> Вообще-то можно было реализовать так, чтобы не нуждаться в дополнительной
> проверке.
> Коли assert() здесь считают инструментом для слабых духом, я подумал и
> решил переписать этот сегмент — тег 20180606-alt1.
> Так что пока второго assert() не будет :)

assert() безумно полезная вещь, но из пропагатора я бы его везде 
повыкидывал... от греха подальше. В этом пакете даже ключик NDEBUG будет 
"миной замедленного действия". И хорошо, что поменяли этот фрагмент, 
вопросов будет меньше.


-- 
Best regards,
Leonid Krivoshein.