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 мог повлиять…
Там и не только Firefox мог повлиять…
bailing wire — упаковочная проволока, обвязочная проволока, не «алюминиевая проволока».
bailing wire — Small rolls of soft iron wire
Откуда взялся алюминий? Алюминиевая проволока — ломкая, и её обычно сдают во вторсырьё.
bailing wire — Small rolls of soft iron wire
Откуда взялся алюминий? Алюминиевая проволока — ломкая, и её обычно сдают во вторсырьё.
Скорее всего имеется ввиду алюминиевая проволока получаемая из старых уличных проводов, которая в советские и несколько позже времена была весьма ходовым крепёжным материалом. Да и сейчас встречается, если удаётся найти провода (сейчас их сразу сдают обычно, так что найти почти нереально)
Если это высказывание несколько локализовать, то можно сказать, что говно и палки — отличный стройматериал.
У меня была чем-то похожая история. Настроил на телефоне с Sailfish OS по расписанию запуск скрипта, который выкачивал обновления большого файла в zip архиве. При запуске руками скрипт отрабатывал отлично, а вот при работе по расписанию unzip в большинстве случаев создавал битый файл, в котором был тупо пропущен кусок. Ровно 64 KiB. Не в хвосте или начале, а в случайном месте! Очень удивительно было искать причины.
Это ещё что, я баг в прошивке винчестера находил.
я мог (при сопутствующей удаче) собирать Хром до 12 раз в час
взгрустнулось, когда вспомнил сколько компилировался хром на моем ноутбуке.
64 с нуля собирается за пару часов на обычном i7. Ребята там серьёзно потрудились над сборкой. А у этого чувака из гугла так вообще goma — распределённая система компиляции хрома. Так что там у него только линковка финальная и осталась небось.
У меня на i5 собиралась часов 4-5.
Как у него собирается я не понял. У него 24 ядра и 64 памяти на рабочей машине для тестов сборки. Хотя он действительно писал, что использует распределенную компиляцию.
Все равно, лишний раз напомнил мне, что пора обновляться.
Как у него собирается я не понял. У него 24 ядра и 64 памяти на рабочей машине для тестов сборки. Хотя он действительно писал, что использует распределенную компиляцию.
Все равно, лишний раз напомнил мне, что пора обновляться.
Это старые так долго были. У меня домашний i5 не больше собирает. Там они придумали джамбо билды — это сильно уменьшает необходимое время.
Всё упирается в генерацию объетков. А линковка может быть и на клиенте. Если кофиги компиляторов везде одинаковые, то почему нет.
напомнило баг с akka (до актора просто не доходили сообщения при async вызове) под .net который воспроизводился только на intel ix-3xxx серии.
Только мы так и не поняли в чём проблема, не было времени разбираться учитывая что сервера были на зеонах 4 поколения а не 3 :)
Только мы так и не поняли в чём проблема, не было времени разбираться учитывая что сервера были на зеонах 4 поколения а не 3 :)
Обычные админские будни (что не делает их менее увлекательными). Basic assumptions are wrong. И обычно процесс дебага проходит где-то по грани между «how much you'd dare» и «don't be silly». Предполагать, что базовые инструменты сломаны — дерзко. Утверждать, что x86_64 переключился в режим z80 глупо. Вот где-то тут обычно тяжкие баги и луркают.
думаю, что корень проблемы в новых патчах Windows. те которые должны были закрыть серьезные «новогодние» уязвимости. плюс к этому стоит добавить 24 ядерный процессор на котором с большой вероятностью не оттестированы данные патчи. также стоит упомянуть, что основные тормоза после применения патча возникают именно на дисковых операциях. возможно патч написал с очередными «компромиссами». много разных «возможно», но попробуйте покопать в эту сторону. например часть патчей исключить из windows и запустить компиляцию. сам имею 2x 10 ядерника и поэтому интересно будет увидеть решение.
Вы это серьёзно? Новогодние патчи настолько круты, что меняют кривизну пространства в районе сервера и заставляют сервер работать неправильно в прошлом?
Это фантастика какая-то. Только непонятно как тут что-либо тестировать: если патчи настолько круты, что влияют не прошлое, то уж на поведение в будущем, после их удаления, они и подавно будут влиять…
Это фантастика какая-то. Только непонятно как тут что-либо тестировать: если патчи настолько круты, что влияют не прошлое, то уж на поведение в будущем, после их удаления, они и подавно будут влиять…
У меня была такая мысль, но я решил оставить сообщение и ждал данного замечания. Но автор два года бьется с несколькими багами и не знает с чем именно имеет дело. Кроме того автор может немного приумножить время по объему затраченного труда…
Если для вас это фантастика, то вы явно далеки от реальности. Ядро виндовс достаточно стабильное, но при этом имеет баги. Автор именно их и копает за что ему огромное спасибо. Почитайте его темы.
Если для вас это фантастика, то вы явно далеки от реальности. Ядро виндовс достаточно стабильное, но при этом имеет баги. Автор именно их и копает за что ему огромное спасибо. Почитайте его темы.
На такой машине, наверняка, есть 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.
Баг компилятора? Линкера? Нет, баг ядра Windows