Инфопульс Украина corporate blog
System Programming
Google Chrome
Debugging
Build automation
Comments 32
+4

Напомнило баг из собственной практики… Довольно большой проект (около получаса полной сборки) собирался под виндой цигвином. Собирался на самом деле с помощью visual studio, но с помощью make от cygwin, а потому в его среде (не я это придумал). И вот если был запущен файрфокс, а в нем были открыты пара страничек с видео (тогда еще в flash), то в какой-то момент cygwin начинал валиться в coredump. Стоило перезапустить файрвокс и сборка опять налаживалась. Вот такие чудеса бывают.

+6
Это совсем другая история. CygWin пытается эмулировать fork — и сделано это через такое место, что высказывание Роланда (сказанное им по похожему, но другому поводу) оказывается весьма к месту: «если говорить начистоту, то сравнивать этот подход со скотчем, алюминиевой проволокой или жевательной резинкой — это оскорбление всех трёх преотличных строительных материалов» (Frankly, I think referring to this scheme with «duct tape», «bailing wire», or «chewing gum» does a disservice to all three of those fine building materials.)

Там и не только Firefox мог повлиять…
+1
Судя по всему, оно даже в исполнении MS магически сделано:
As a final example, the Linux fork syscall has no documented equivalent for Windows. When a fork syscall is made on WSL, lxss.sys does some of the initial work to prepare for copying the process. It then calls internal NT APIs to create the process with the correct semantics and create a thread in the process with an identical register context. Finally, it does some additional work to complete copying the process and resumes the new process so it can begin executing.

Прям даже интересно стало, как это в Cygwin реализовали.
+2
Нашел. Люто, однако.
Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Win32 CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's .data and .bss subsections by copying from its own address space into the suspended child's address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.

И всему этому мешает рандомизация адресного пространства (ASLR), отсутствие адресо-незаависимого кода (PIC) в Win, и другие радости.
-1
bailing wire — упаковочная проволока, обвязочная проволока, не «алюминиевая проволока».
bailing wire — Small rolls of soft iron wire
Откуда взялся алюминий? Алюминиевая проволока — ломкая, и её обычно сдают во вторсырьё.
0
Скорее всего имеется ввиду алюминиевая проволока получаемая из старых уличных проводов, которая в советские и несколько позже времена была весьма ходовым крепёжным материалом. Да и сейчас встречается, если удаётся найти провода (сейчас их сразу сдают обычно, так что найти почти нереально)
+4
Что-то мне подсказывает, что не стоит пытаться дословно переводить англоязычные аналоги выражения «из говна и палок», тогда нашему «примотай проволокой» (конечно-же алюминейвой, толщиной в 1,5-2 мм, которая была в каждой квартире) оно очень даже хорошо будет соответствовать.
+4
Если это высказывание несколько локализовать, то можно сказать, что говно и палки — отличный стройматериал.
0
Напомнило хайку про ошибки:
Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.
©

+2
У меня была чем-то похожая история. Настроил на телефоне с Sailfish OS по расписанию запуск скрипта, который выкачивал обновления большого файла в zip архиве. При запуске руками скрипт отрабатывал отлично, а вот при работе по расписанию unzip в большинстве случаев создавал битый файл, в котором был тупо пропущен кусок. Ровно 64 KiB. Не в хвосте или начале, а в случайном месте! Очень удивительно было искать причины.
0
Баги в винтах, похоже, обычное дело. У меня есть диск (Samsung), который при записи пропускает серию из 69 блоков — всегда в разных местах. Просто не пишет их на блины, оставляя там старые данные посреди новых.
+1
я мог (при сопутствующей удаче) собирать Хром до 12 раз в час

взгрустнулось, когда вспомнил сколько компилировался хром на моем ноутбуке.
0
64 с нуля собирается за пару часов на обычном i7. Ребята там серьёзно потрудились над сборкой. А у этого чувака из гугла так вообще goma — распределённая система компиляции хрома. Так что там у него только линковка финальная и осталась небось.
0
У меня на i5 собиралась часов 4-5.
Как у него собирается я не понял. У него 24 ядра и 64 памяти на рабочей машине для тестов сборки. Хотя он действительно писал, что использует распределенную компиляцию.
Все равно, лишний раз напомнил мне, что пора обновляться.
0
Это старые так долго были. У меня домашний i5 не больше собирает. Там они придумали джамбо билды — это сильно уменьшает необходимое время.
0
Может быть, не знаю. Это полтора-два года назад было. Я дженту использовал, и поскольку это не имело отношение к работе, повышение энторопии вселенной меня довольно быстро утомило. Особенно, когда сваливались апдейты хромиума, лвм и т.д., раздражало.
0
Всё упирается в генерацию объетков. А линковка может быть и на клиенте. Если кофиги компиляторов везде одинаковые, то почему нет.
0
напомнило баг с akka (до актора просто не доходили сообщения при async вызове) под .net который воспроизводился только на intel ix-3xxx серии.
Только мы так и не поняли в чём проблема, не было времени разбираться учитывая что сервера были на зеонах 4 поколения а не 3 :)
+3
Обычные админские будни (что не делает их менее увлекательными). Basic assumptions are wrong. И обычно процесс дебага проходит где-то по грани между «how much you'd dare» и «don't be silly». Предполагать, что базовые инструменты сломаны — дерзко. Утверждать, что x86_64 переключился в режим z80 глупо. Вот где-то тут обычно тяжкие баги и луркают.
0
думаю, что корень проблемы в новых патчах Windows. те которые должны были закрыть серьезные «новогодние» уязвимости. плюс к этому стоит добавить 24 ядерный процессор на котором с большой вероятностью не оттестированы данные патчи. также стоит упомянуть, что основные тормоза после применения патча возникают именно на дисковых операциях. возможно патч написал с очередными «компромиссами». много разных «возможно», но попробуйте покопать в эту сторону. например часть патчей исключить из windows и запустить компиляцию. сам имею 2x 10 ядерника и поэтому интересно будет увидеть решение.
+4
Вы это серьёзно? Новогодние патчи настолько круты, что меняют кривизну пространства в районе сервера и заставляют сервер работать неправильно в прошлом?

Это фантастика какая-то. Только непонятно как тут что-либо тестировать: если патчи настолько круты, что влияют не прошлое, то уж на поведение в будущем, после их удаления, они и подавно будут влиять…
-1
У меня была такая мысль, но я решил оставить сообщение и ждал данного замечания. Но автор два года бьется с несколькими багами и не знает с чем именно имеет дело. Кроме того автор может немного приумножить время по объему затраченного труда…

Если для вас это фантастика, то вы явно далеки от реальности. Ядро виндовс достаточно стабильное, но при этом имеет баги. Автор именно их и копает за что ему огромное спасибо. Почитайте его темы.
+2
Если для вас это фантастика, то вы явно далеки от реальности.
Да, для нас звучит фантастикой, что новогодние патчи 2018 года могли улететь в прошное и вызвать баги в 2016-м году. Вы твёрдо уверены, что это именно мы далеки от реальности?
+1
На такой машине, наверняка, есть RAID контроллер, у которого есть Кеш, который используется до записи данных на диск.
И я думаю проблема скорее в нем, чем в ОС.
Иначе с багом столкнулись бы намного раньше. Вы же не думаете, что только в гугле запускают Файлы сразу после сборки на высокозагруженных машинах?
+1
На такой машине нет никакого RAID'а ибо смысла в нём — нуль: если это билд-сервер, то на нём по определению ничего особо важного не хранится.
+2

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


I’m always ready to suspect gcc since it has been a cause of so much trouble in the past.
— Ron Minnich, main author of CoreBoot and LinuxBIOS.
-4
Может у него на компьютере используется RAM-disk который имеет баги эмуляции диска.
Only those users with full accounts are able to leave comments., please.