Pull to refresh

Comments 32

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

Это совсем другая история. 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 мог повлиять…
UFO just landed and posted this here
UFO just landed and posted this here
bailing wire — упаковочная проволока, обвязочная проволока, не «алюминиевая проволока».
bailing wire — Small rolls of soft iron wire
Откуда взялся алюминий? Алюминиевая проволока — ломкая, и её обычно сдают во вторсырьё.
Скорее всего имеется ввиду алюминиевая проволока получаемая из старых уличных проводов, которая в советские и несколько позже времена была весьма ходовым крепёжным материалом. Да и сейчас встречается, если удаётся найти провода (сейчас их сразу сдают обычно, так что найти почти нереально)
UFO just landed and posted this here
Если это высказывание несколько локализовать, то можно сказать, что говно и палки — отличный стройматериал.
А если облагородить, то спички и жёлуди.
Напомнило хайку про ошибки:
Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.
©

©

Но ведь…
The Free Software Foundation claims no copyright on this joke.
У меня была чем-то похожая история. Настроил на телефоне с Sailfish OS по расписанию запуск скрипта, который выкачивал обновления большого файла в zip архиве. При запуске руками скрипт отрабатывал отлично, а вот при работе по расписанию unzip в большинстве случаев создавал битый файл, в котором был тупо пропущен кусок. Ровно 64 KiB. Не в хвосте или начале, а в случайном месте! Очень удивительно было искать причины.
Баги в винтах, похоже, обычное дело. У меня есть диск (Samsung), который при записи пропускает серию из 69 блоков — всегда в разных местах. Просто не пишет их на блины, оставляя там старые данные посреди новых.
я мог (при сопутствующей удаче) собирать Хром до 12 раз в час

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

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

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

Есть по этому поводу известная цитата, довольно известного разработчика. Там правда не про 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.
Может у него на компьютере используется RAM-disk который имеет баги эмуляции диска.
Sign up to leave a comment.