Какова самая жесткая ошибка, которую Вы когда-нибудь находили и фиксировали? [закрытый]

Не уверенный это является самым жестким, но несколько лет назад у меня была программа Java, которая использовала XMLEncoder для сохранения/загружения конкретного класса. По некоторым причинам класс не работал правильно. Я сделал простой двоичный поиск ошибки и обнаружил, что ошибка происходила, после одного вызова функции, но перед другим вызовом, который должен был быть невозможным. 2 часа спустя я не понял его, хотя момент я сделал перерыв (и уезжал), я осознал проблему. Это сложилось эти XMLEncoder, создавал созданный из значения по умолчанию экземпляр класса вместо того, чтобы иметь и класс и ссылку на класс, относятся к тому же объекту. Так, в то время как я думал два вызова функции, где оба на членах того же экземпляра конкретного класса, каждый был на самом деле на созданной из значения по умолчанию копии.

Было жестко для нахождения, так как я знал , они были оба ссылками на тот же класс.

Когда я сначала запустил в компании, я работаю, поскольку я сделал много CPR для изучения продуктов.

Этот встроенный продукт, записанный в блоке HC11, имел функцию, которая происходила каждые восемь часов. Оказывается прерыванием, которое постепенно уменьшилось, значение стреляло во время кода, который проверял счетчик. Хлопнувший некоторый CLI/STI вокруг кода и это было прекрасно. Я разыскал его путем взламывания события для случая дважды в секунду, а не каждые восемь часов.

урок я извлек уроки из этого, был при отладке кода, который нечасто перестал работать, я должен проверить переменные, используемые прерываниями сначала.

Был код, который устанавливает некоторую дату окончания срока действия на текущую дату плюс один год путем добавления 1 к текущему году и явления вовремя и месяцу как то же. Это неудавшееся достижение 29 февраля 2008, потому что база данных отказалась принимать 29 февраля 2009!!

не знают, имеет ли это право на то, чтобы быть 'жестким', но это был странный код, который был переписан сразу, конечно!

Это немного вне темы (который является, почему я сделал его сообществом).

, Но Ошибка Ellen Ullman является фантастической вымышленной книгой об этой самой теме.

Не одно мое, но коллега в предыдущем месте занятости провело 3 дня, отлаживая его JavaScript popout управление редактора (это было долгое время назад, перед радостями платформ), только чтобы найти, что это пропускало единственную точку с запятой на полпути вниз один из ее огромных базовых файлов.

Мы назвали его "самой дорогой точкой с запятой в мире", но я уверен, что там было намного хуже на протяжении всей истории!

давно, я записал объектно-ориентированный язык с помощью C и (символьно-ориентированную) библиотеку форм; каждая форма была объектом, формы могли содержать подчиненные формы и так далее. Сложное приложение выставления счета записанное использование этого хорошо работало бы в течение приблизительно 20 минут, тогда случайные посторонние символы, появится время от времени на экране. Еще после нескольких минут использования приложения, машина перезагрузила бы, зависла бы, или что-то решительное.

это оказалось плохим освобождением, следующим из неверно направленной делегации в обрабатывающем сообщение механизме; неправильные направленные сообщения делегировались дерево вместимости, когда у нас закончились суперклассы, и иногда родительские объекты будут иметь методы с тем же именем, таким образом, это, казалось бы, работало бы большую часть времени. Остальная часть времени это освободило бы маленький буфер (приблизительно 8 байтов) в неправильном контексте. Указатель, освобождаемый неправильно, был на самом деле мертвой памятью, используемой промежуточным счетчиком для другой операции, таким образом, ее значение имело тенденцию сходиться на нуле после времени.

да, неверный указатель пересекся бы через область карты распределения памяти экрана, продвигающегося к нулевой странице, где это в конечном счете перезаписало вектор прерывания и уничтожило ПК

, это было путем перед современными средствами отладки, таким образом выясняя то, что происходило, занял несколько недель...

Нарушение памяти "кучи" в текстовых средствах редактирования, которые я использовал. После многих месяцев (...) ища его, я нашел решение, работающее с другим программистом, коллегой, отлаживающим проблему. Этот самый экземпляр убедил меня в значении работы в командах и Гибкий в целом. Читайте больше об этом в мой блог

Существуют несколько те, я могу вспомнить, большинство из них вызванный мной:). Почти evey один из них было нужно большое главное царапание.

1. я был частью проекта Java (толстый клиент), код Java раньше работал хорошо над сборками ванили или новыми машинами без проблемы, но, когда установлено на ноутбуках представления, это внезапно прекратило работать и начало бросать stackdump. Дальнейшее расследование показало, что код полагался на пользовательский dll, который имеет конфликт с cygwin. Это не конец истории, мы, как предполагалось, установили его на 5 других machies и предположили то, что, на одной из машин это снова разрушило! На этот раз преступник был jvm, код, который мы дали, был для созданного использования, Sun Microsystems jdk и машина имели jvm IBM.

2. Другой экземпляр, который я могу вспомнить, имеет отношение к пользовательскому коду обработчика событий, код был единицей, протестированной и проверенной, наконец когда я удалил печать () операторы, БУМ!!. Когда мы отладили, код работал, отлично добавление к нашему должно. Я должен был обратиться к медитации дзэн (дремота на столе), и произошло, что мог бы быть временный anamoly! Событие, которое мы делегировали, инициировало функцию даже, прежде чем условие было установлено, операторы печати & режим отладки дал достаточно времени для условия, которое будет установлено и так работал правильно. Вздох облегчения и некоторый рефакторинг решили проблему.

3. Один прекрасный день я решил, что некоторые объекты области должны были реализовать интерфейс Clonable, вещи были прекрасны. После нескольких недель мы заметили, что приложение начало вести себя странно. Предположить что? мы добавляли эти мелкие копии к классам набора и удалять (), методы на самом деле не очищали содержание правильно, (должный копировать ссылки, указывающие на тот же объект). Это вызвало некоторый серьезный образцовый обзор и несколько поднятых бровей.

Противный катастрофический отказ в приложении для GUI, записанном в Turbo Pascal. Три дня плюс то, прежде чем я обнаружил, единственным продвижением в отладчик, на уровне машинного кода, по простому и очевидно исправляю код, что я помещал 16-разрядное целое число на стек вызовов для функции, ожидающей 32-разрядный (или некоторое такое несоответствие)

Теперь, я мудр к этому, хотя современные компиляторы больше не позволяют такую проблему.

Непосредственно перед тем, как Интернет завоевал популярность, мы работали над основанным на модеме домашним банковским приложением (Первое в Северной Америке).

За три дня до выпуска, мы были (почти) по графику и планировали использовать остающееся время для теста exhaustivly система. У нас был план тестирования, и затем в списке была модемная связь.

прямо о тогда, наш клиент приехал врывающийся в желание последнего обновления компонентов. Конечно, я был полностью против этого, но я был отвергнут. Мы работали допоздна в течение трех дней, добавляя глупую вещь и получили ее работающий датой выпуска. Мы сделали крайний срок и передали 2 000 гибких дисков клиентам.

На следующий день после выпуска, я возвратился к своему расписанию тестирования и продолжил тестировать модемный коммуникационный модуль. Очень к моему удивлению, я нашел, что модем случайным образом не соединится. Примерно тогда наши телефоны начали вешать трубку рычаг с сердитыми клиентами, не бывшими способными использование их приложение.

После большого количества knashing зубов и получения по запросу волос, я проследил проблему до инициализации последовательного порта. Младший программист прокомментировал запись к одному из регистров управления. Регистр остался неинициализированным, и было приблизительно 10%-й шанс, что он будет содержать недопустимое значение - в зависимости от конфигурации пользователя, и какие приложения он запустил заранее.

, Когда спрошено об этом, программист утверждал, что это заставило его работать над его машиной.

, Таким образом, мы должны были повторно записать тех 2000 + дискеты и разыскать каждого клиента для вспоминания их. Не забавная вещь сделать, особенно с уже разочарованной командой.

Мы получили большой удар на том. Наш клиент утверждал, что, потому что это была наша ошибка, нам придется поглотить стоимость отзыва. Наше расписание для следующего выпуска было отложено месяц. И наши отношения с клиентом были запятнаны.

В наше время, я намного менее гибок с дополнениями функции на последней минуте, и я пытаюсь связаться лучше со своей командой.

Многопоточные приложения, где выполнение в отладке прекрасно, но как только Вы работаете в выпуске, он идет не так, как надо из-за немного отличающейся синхронизации. Даже добавление Консоли. WriteLine звонит в продукт, который основная отладка outpit заставила действительно изменение в синхронизации для него работать и не показывать проблеме. Оснастите неделю, чтобы найти и зафиксировать несколько строк кода, которому было нужно изменение.

Благодаря флэш-памяти вдохновения это не заняло слишком много времени разыскивать, но было немного нечетно, тем не менее. Небольшое приложение, только используемое другими людьми в отделе ИТ. Это соединяется в свою очередь со всем настольным ПК в домене. Многие выключены, и соединение берет ВОЗРАСТЫ для таймаута, таким образом, оно работает на пуле потоков. Это просто сканирует AD и очереди тысячи объектов работы к пулу потоков. Все хорошо работали. Несколько лет спустя я говорил с другим членом штата, который на самом деле использует этот appliacation, и он упомянул, что это сделало ПК неприменимым. В то время как это выполняло попытку открыться, веб-страницы или просмотреть сетевой диск займут минуты, или просто никогда не происходить.
проблема оказалась полуоткрытым пределом tcp XP. Исходный ПК был сдвоенным процессором, таким образом.NET выделяет 50 (или 100, не уверенный) потоки к пулу, без проблем. Теперь у нас есть двухъядерный сдвоенный процессор, у нас теперь есть больше потоков в пуле потоков, чем у Вас могут быть полуоткрытые соединения, таким образом, другая сетевая активность становится невозможной, в то время как приложение работает.

Это теперь фиксируется, это проверяет с помощью ping-запросов машины прежде, чем попытаться соединиться с ними так, тайм-аут намного короче и использует маленькое постоянное число потоков, чтобы сделать фактическую работу.

Разработанный многопоточное в реальном времени (дрожь) система однажды, который опросил изображения от нескольких сетевых камер наблюдения и сделал все виды волшебства на изображениях.

ошибка просто заставила систему отказать, некоторый критический раздел, с которым неправильно обрабатывают, конечно. Я понятия не имел, как инициировать отказ непосредственно, но должен был ожидать его для появления, который был об однажды за три или четыре дня (разногласия: приблизительно 1 в 15000000 на 30 кадр/с).

я должен был подготовить все, что я, выходные сигналы отладки, пачкающие код, мог проследить инструменты, удаленные средства отладки на камере и списке продолжается. Тогда я просто должен был ожидать два три дня и надежда поймать всю информацию для определения местоположения провального взаимного исключения или что бы то ни было. Потребовалось четыре из этих выполнений, прежде чем я разыскал его, четыре недели!. Еще одно выполнение и я повредили бы потребительский крайний срок..

Это было катастрофическим отказом нарушения прав доступа.
от катастрофического отказа выводят, я мог только выяснить, что параметр на стеке вызовов был поврежден.
причиной был этот код :

n = strlen(p->s) - 1;
if (p->s[n] == '\n')
   p->s[n] = '\0';    

, если длина строки была 0, и параметр на стеке выше, оказывается, находятся на 0x0Axxxxxxx
адреса ==> повреждение стека
, К счастью, этот код был достаточно близок к фактическому местоположению катастрофического отказа, так просмотр (ужасного) исходного кода был способом найти culrpit

Самая жесткая ошибка, которую я когда-либо должен был исправлять, была той, которую я повысил сам - я заключил контракт как тестер на крупную телекоммуникационную компанию, тестируя продукт другой компании. Несколько лет спустя у меня был контракт с другой компанией и первой вещью, которую они дали мне, были ошибки, которые я повысил сам.

Это было состояние состязания ядра в, встроенная операционная система, записанная в 6 809 ассемблерах и BCPL. Среда отладки состояла из специального printf, который записал в последовательное устройство; никакой необычный IDE не наполняет в этой установке.

Занял долгое время для фиксации, но это было огромное повышение удовлетворенности когда я наконец nutted это.

В игре, над которой я работал, определенный спрайт больше не отображался в режиме выпуска, но работал нормально в режиме отладки и только в одном конкретном издании. Другой программист пытался найти эту ошибку в течение 2 дней, а затем ушел в отпуск. В итоге мне пришлось попытаться найти ошибку примерно за 5 часов до релиза.

Так как сборка Debug работала, мне пришлось отлаживать релизную сборку. Visual Studio поддерживает некоторую отладку в сборке выпуска, но вы не можете полагаться на все, что отладчик говорит вам, чтобы быть правильным (особенно с агрессивными настройками оптимизации, которые мы использовали). Поэтому мне пришлось проходить через половину списков кода и половину списков ассемблера, иногда просматривая объекты непосредственно в шестнадцатеричном дампе вместо хорошо отформатированного представления отладчика.

Потратив некоторое время на то, чтобы убедиться, что все правильные вызовы отрисовки были сделаны, я обнаружил, что цвет материала спрайта был неправильным - он должен был быть полностью прозрачным оранжевым, но вместо этого был установлен на черный и полностью прозрачный , Цвет был взят из палитры, находящейся в массиве const в нашем классе EditionManager. Первоначально он был настроен как правильный оранжевый цвет, но когда фактический цвет был получен из кода рисования спрайта, он снова стал таким прозрачным черным. Я установил точку останова памяти, которая была запущена в конструкторе EditionManager. Запись в другой массив привела к изменению значения в массиве палитр.

Как выяснилось, другой программист изменил существенное перечисление системы:

enum {
    EDITION_A = 0,
    EDITION_B,
    //EDITION_DEMO,
    EDITION_MAX,

    EDITION_DEMO,
};

Он поставил EDITION_DEMO сразу после EDITION_MAX , и массив, в который производилась запись, был проиндексирован с помощью EDITION_DEMO , поэтому он перетек в палитру и установил там неправильные значения. Однако я не мог изменить перечисление обратно, так как номера изданий больше не могли меняться (они использовались в двоичной передаче). Поэтому в итоге я сделал запись EDITION_REAL_MAX в перечислении и использовал ее в качестве размера массива.

Я работаю в большом общественном колледже, и в прошлом году мы перешли с Blackboard на Moodle , Moodle использует номенклатуру «курсов» и «групп». Курс может быть, например, «Микроэкономика ECO-150», а группы - это то, что мы бы назвали разделами (OL1, OL2, 01, 14, W09 в качестве примеров).

В любом случае мы примитивны. У нас даже нет LDAP. Все это текстовые файлы, электронные таблицы Excel и GD базы данных Microsoft Access. Моя работа заключается в создании веб-приложения, которое принимает все вышеперечисленное в качестве входных данных и создает еще больше текстовых файлов, чем может быть затем загружено в Moodle для создания курсов, групп в курсах и пользователей и размещения пользователей в курсах и группах. Вся установка просто византийская, примерно с 17 отдельными шагами, которые необходимо выполнить по порядку. Но это работает и заменяет процесс, который раньше занимал несколько дней в самое загруженное время семестра.

Но была одна проблема. Иногда мы получали то, что я назвал «Сумасшедшие группы». Таким образом, вместо создания курса с 4 группами по 20 студентов в каждой, будет создан курс с 80 группами по 1 студенту в каждой. Хуже всего то, что программно невозможно попасть в cpanel (к которому у меня нет доступа), чтобы удалить группу после ее создания. Это ручной процесс, который занимает около 5 нажатий кнопок. Таким образом, каждый раз, когда создавался курс с Crazy Groups, мне приходилось либо удалять курс, что предпочтительно, но не вариант, если учитель уже начал добавлять контент в курс, либо мне приходилось тратить час, постоянно следуя той же схеме: Выберите группу, отобразите группу, отредактируйте группу, удалите группу, вы действительно хотите удалить группу? Да ради бога!

И не было никакого способа узнать, возникли ли сумасшедшие группы, если только вы вручную не открывали каждый курс и не просматривали (с сотнями курсов) или пока не получили жалобу. Сумасшедшие группы казались случайными, и форумы Google и Moodle не помогли, похоже, все остальные используют эту штуку под названием LDAP или РЕАЛЬНУЮ базу данных, поэтому они никогда не сталкивались с проблемой.

Наконец, после Я не знаю, сколько времени исследовал и сколько времени удалял сумасшедшие группы, чем я хотел бы признаться, я понял это. Это была ошибка в Moodle, а не в моем коде! Это доставило мне немало удовольствия. Вы видите, что способ создать группу - просто попытаться зарегистрировать кого-то в группе, и если группа еще не существует, Moodle создает ее. И это отлично работало для групп с именами OL1 или W12 или даже SugarCandyMountain, но если вы попытались создать группу с номером в качестве имени, скажем 01 или 14, ТОГДА возникнут сумасшедшие группы. Moodle неправильно сравнивает числа как строки. Независимо от того, сколько групп с именем 01 внутри курса есть, он всегда будет думать, что группа еще не существует, и поэтому создаст ее. Вот как получается 80 групп по 1 человеку в каждой.

Гордый своим открытием, я зашел на форум Moodle и опубликовал свои результаты с инструкциями по воспроизведению проблемы по желанию. Это было около года назад, и, насколько мне известно, проблема все еще существует внутри Moodle, никто, кажется, не заинтересован ее исправлять, потому что никто, кроме нас, примитивов, не использует регистрацию текстовых файлов. Мое решение, просто чтобы убедиться, что все имена наших групп содержат хотя бы 1 нечисловой символ. Сумасшедшие группы ушли навсегда, по крайней мере, для нас, но я сочувствую тому парню, который работает в муниципальном колледже во внешней Монголии, который только что загрузил семестровые курсы и вот-вот проснется. По крайней мере, на этот раз Google может ему помочь, потому что я написал ему это сообщение в бутылке о волнах киберпространства.

Тупиковая ситуация в серверном приложении Java. Но не простой тупик с двумя потоками. Я обнаружил тупик с восемью потоками. Поток 1 ожидает потока 2, который ожидает поток 3 и т. Д., И, наконец, поток 8 ждет поток 1.

Мне потребовался целый день, чтобы понять, что происходит, а затем всего 15 минут, чтобы исправить это. Я использую eclipse для отслеживания около 40 потоков, пока не обнаружу тупик.

Однажды у меня была ошибка с пользовательской программой синхронизации. Он использовал отметку даты / времени файлов / папок для сравнения того, что было изменено для синхронизации данных с флэш-ключа с общим сетевым ресурсом в Windows, с некоторой дополнительной целостностью и встроенной бизнес-логикой.

Однажды, как сообщил оператор что его синхронизация длилась вечно ... после просмотра журналов по какой-то причине программа посчитала, что каждый файл на флешке (или сервере) был на 3 часа старше, чем должен быть, обновляя все 8 гигабайт данных! Я использовал UTC, как, черт возьми, это могло быть?

Оказывается, этот конкретный оператор действительно установил свой часовой пояс на тихоокеанское время, а не на восточное, что вызвало проблему, но этого не должно было быть, потому что весь код использовал UTC - боже, что это могло быть ?! Это сработало при тестировании в моей локальной системе ... что дает?

На этом этапе мы попросили всех операторов убедиться, что их ноутбуки были настроены на восточное время перед синхронизацией, и ошибка оставалась в очереди, пока у нас не было больше времени для расследования.

Затем наступил октябрь и БУМ! Летнее время! Какого черта!? Теперь все жаловались, что синхронизация длилась вечно! Пришлось исправить, и быстро!

Я отследил это, изменив тестовый пример так, чтобы он запускался с карты памяти, а не с моего локального жесткого диска, и, конечно же, это не удалось ... уф, должна быть штука с картой памяти - подождите сек, он отформатирован FAT32 ... А-ХА! FAT32 использует местное время при записи метки времени файла!

http://msdn.microsoft.com/en-us/library/ms724290 (VS.85) .aspx

Итак, программное обеспечение было переписано таким образом, что когда записывая на носитель FAT32, мы программно устанавливаем его на UTC ...

DevExpress XPO при общении с базой данных Oracle происходит резкий сбой (например, программа завершает работу без уведомления), если путь к каталогу, в который установлено приложение, не содержит хотя бы одного пробела, а словарь данных XPO проверяет for не на 100% правильно помещен в базу данных.

Проблема описана здесь .

Я могу сказать вам следующее: я был> <близок к тому, чтобы плакать, когда мы выяснили, как обойти проблема. Я до сих пор не знаю, какова реальная причина проблемы, но наш продукт не будет поддерживать Oracle в будущей версии, поэтому я на самом деле не сообщаю ... больше.

В CS435 в Purdue нам пришлось написать трассировщик лучей для нашего последнего проекта. Все, что я производил, имело сильный оранжевый оттенок, но я мог видеть каждый из объектов в моей сцене. В конце концов я сдался и отправил его как есть, и попросил профессора просмотреть мой код, чтобы найти ошибку, а когда он не смог ее найти, я провел большую часть лета, копаясь, чтобы найти, что, черт возьми, не так.

Погруженный глубоко в код, как часть функции вычисления цвета, я наконец понял, что делю int и передаю его функции OpenGL, которая ожидала значение с плавающей запятой. Один из цветовых компонентов был достаточно низким на протяжении большей части сцены, чтобы округлить его до 0, вызывая оранжевый оттенок. Преобразование его в число с плавающей запятой только в одном месте (до деления) исправило ошибку.

Всегда проверяйте вводимые данные и ожидаемые типы.

Коробка разбилась на сайте крупного заказчика, и нам пришлось подключиться через сеанс WebX к компьютеру ИТ-специалиста, который был подключен к нашей коробке. Я копался около часа, собирая трассировки стека, дампы регистров, статистику, счетчики,

Их ИТ-специалисты прислали мне по электронной почте стенограмму моего сеанса, и я приступил к работе.

Через несколько часов я отследил ее до массива структур, которые содержал пакетные метаданные, за которыми следовали пакетные данные. Одна из метаданных пакета была повреждена, и казалось, что она была перезаписана несколькими байтами пакетных данных. У Bugzilla не было записей о чем-либо подобном.

Углубляясь в код, я проверил все очевидные вещи. Код, копирующий пакетные данные в буфер, тщательно следил за тем, чтобы не выходить за его пределы: буфер был размером MTU для интерфейса, а процедура копирования проверяла, что данные не превышают размер MTU. Мои дампы памяти позволили мне подтвердить, что да, foo-> bar действительно было 4, когда произошел сбой. Ничего не сложилось. Ничего не было неправильным, что должно было вызвать проблему. В следующем заголовке было то, что выглядело как 16 байт пакетных данных.

Пару дней спустя я начал проверять все, что мог придумать.

Я заметил, что длина буфера данных действительно правильная. . То есть количество байтов от начала данных до конца данных было MTU, даже если следующий заголовок начинался с MTU-16.

Когда эти структуры были malloc'd, указатели на каждый элемент были помещены в массив , и я сбросил этот массив. Я начал измерять расстояние между указателями. 6888 ... 6888 ... 6888 ... 6872 ... 6904 ... 6880 ... 6880 ...

Подождите, что?

Я начал смотреть на внутренние указатели и смещения в обеих структурах . Все сложилось. Просто это выглядело как одна моя плохая структура - та, которая ' d был частично затертен - всего на 16 байт в памяти оказалось слишком мало.

Процедура выделения выделила этим ребятам блок, а затем разделила их на цикл:

   for (i = 0; i < NUM_ELEMS; i++) {
      array[i] = &head[i*sizeof(foo)];
   }

(с учетом выравнивания и т. д.) .

Когда массив был заполнен, значение моего поврежденного указателя должно было быть прочитано как 0x8a112 8 ac вместо 0x8a112 9 ac.

Я пришел к выводу, что Я стал жертвой 1-битной ошибки памяти во время выделения (я знаю, я знаю! Я тоже не поверил, но мы видели их раньше на этом оборудовании - значения NULL, которые читались как 0x00800000) . В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

Процедура выделения памяти распределила этих парней как фрагмент, а затем разделила их в цикле:

   for (i = 0; i < NUM_ELEMS; i++) {
      array[i] = &head[i*sizeof(foo)];
   }

(с учетом выравнивания и т. Д.).

Когда массив был заполнен значением для моих поврежденных указатель должен быть прочитан как 0x8a112 8 ac вместо 0x8a112 9 ac.

Я пришел к выводу, что я стал жертвой 1-битной ошибки памяти во время распределение (знаю, знаю! Я тоже не поверил, но мы видели их раньше на этом оборудовании - значения NULL, которые читались как 0x00800000). В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

Процедура выделения памяти распределила этих парней как фрагмент, а затем разделила их в цикле:

   for (i = 0; i < NUM_ELEMS; i++) {
      array[i] = &head[i*sizeof(foo)];
   }

(с учетом выравнивания и т. Д.).

Когда массив был заполнен значением для моих поврежденных указатель должен быть прочитан как 0x8a112 8 ac вместо 0x8a112 9 ac.

Я пришел к выводу, что я стал жертвой 1-битной ошибки памяти во время распределение (знаю, знаю! Я тоже не поверил, но мы видели их раньше на этом оборудовании - значения NULL, которые читались как 0x00800000). В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

   for (i = 0; i < NUM_ELEMS; i++) {
      array[i] = &head[i*sizeof(foo)];
   }

(с учетом выравнивания и т. Д.).

Когда массив был заполнен, значение моего поврежденного указателя должно было быть прочитано как 0x8a112 8 ac вместо 0x8a112 9 ac.

Я пришел к выводу, что я стал жертвой 1-битной ошибки памяти во время выделения (знаю, знаю! Я тоже не поверил, но мы видели их раньше на это оборудование - значения NULL, которые читались как 0x00800000). В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

   for (i = 0; i < NUM_ELEMS; i++) {
      array[i] = &head[i*sizeof(foo)];
   }

(с учетом выравнивания и т. Д.).

Когда массив был заполнен, значение моего поврежденного указателя должно было быть прочитано как 0x8a112 8 ac вместо 0x8a112 9 ac.

Я пришел к выводу, что я стал жертвой 1-битной ошибки памяти во время выделения (знаю, знаю! Я тоже не поверил, но мы видели их раньше на это оборудование - значения NULL, которые читались как 0x00800000). В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

Я пришел к выводу, что я стал жертвой 1-битной ошибки памяти во время выделения (я знаю, я знаю! Я тоже не поверил, но мы видели их раньше на этом оборудовании - - значения NULL, которые читались как 0x00800000). В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

Я пришел к выводу, что я стал жертвой 1-битной ошибки памяти во время выделения (я знаю, я знаю! Я тоже не поверил, но мы видели их раньше на этом оборудовании - - значения NULL, которые читались как 0x00800000). В любом случае мне удалось убедить моего босса и коллег в том, что другого разумного объяснения не было, и что мое объяснение в точности объясняет то, что мы видели.

Итак, коробка RMA'd.

может показаться забавным, но когда я учился, я потратил весь день, пытаясь выяснить, почему статус if всегда оценивается как истина. Я использовал = вместо ==: я переписал все дважды на другой компьютер :)

В Python у меня был поток, делающий что-то вроде этого:

while True:
    with some_mutex:
        ...
        clock.tick(60)

clock.tick (60) приостанавливает поток, чтобы он выполняется не более 60 раз в секунду. Проблема заключалась в том, что большую часть времени программа просто показывала черный экран. Если я позволю ему поработать какое-то время, он, наконец, покажет экран игры.

Это потому, что поток делал паузу , поддерживая мьютекс . Таким образом, он редко позволяет другим потокам получать мьютекс. Здесь это может показаться очевидным, но мне потребовалось два дня, чтобы понять это. Решение состоит в том, чтобы просто удалить уровень отступа:

while True:
    with some_mutex:
        ...

    clock.tick(60)

Самая серьезная ошибка должна быть, когда программист выводит в журнал «Общая ошибка!». Посмотрев код, он везде разлетелся с текстом «Общая ошибка!». Попробуйте пригвоздить его.

По крайней мере, написать макрос для вывода __LINE__ или __FUNCTION__ было бы немного полезнее, чтобы добавить к выводам отладки.

Унаследованное приложение на основе базы данных (с доступной только частью исходного кода) аварийно завершило работу, когда один конкретный пользователь получил доступ к определенной функции инвентаризации. Он отлично работал для всех остальных пользователей. Профиль пользователя правильно? Нет. При входе в систему как другой пользователь (даже как администратор) у одного и того же пользователя была такая же проблема.

Проблема с компьютером? Нет. Тот же пользователь, другой компьютер (под ее логином или любым другим логином) все равно вылетел.

Проблема: при входе в программу отображалась заставка авторского права, которую можно было закрыть либо щелчком «X» для закрытия окна, либо нажатием любой клавиши. При входе в систему этот пользователь всегда щелкал «X» там, где другие пользователи всегда нажимали клавишу. Это привело к утечке памяти, которая возникла, но только при доступе к инвентаризации.

Исправление: не нажимайте X.

Гонка между методом ToString класса OracleDecimal (который P / вызывает собственную версию той же функциональности) и сборщиком мусора, вызванная отсутствующим вызовом GC.KeepAlive, который может вызвать OracleDecimal.ToString ( ), чтобы вернуть по существу произвольный мусор, если его пространство кучи было перезаписано до завершения вызова.

Я написал подробный отчет об ошибке и никогда не получал ответа, хотя я знаю, что это все еще существует. У меня даже был тестовый набор, который ничего не делал, кроме как создавать новые OracleDecimal представления числа 1, вызывать на них ToString и сравнивать результат с «1». Он будет терпеть неудачу каждый десятимиллионный раз или около того с сумасшедшей тарабарщиной (огромные числа, отрицательные числа и даже буквенно-цифровые строки мусора).

Будьте осторожны со своими вызовами P / Invoke! Это законно для.

Самые сложные ошибки, которые я когда-либо исправлял, на самом деле появились довольно рано в моей карьере. Я работал над системой реального времени для электростанции, которая использовала пары компьютеров GEC 2050 с общей памятью.

RTOS 2050 имела основную таблицу планирования, которая состояла из одного слота на процесс, содержимое которого было либо добавлением 1, инструкция X для неактивного процесса или переход для исполняемого процесса. Выполнение этой таблицы с X, установленным в ноль, означало, что первый запускаемый процесс автоматически вводился с регистром X, являющимся номером процесса. Кто бы это ни разработал, очевидно, он чувствовал себя очень умным!

В архитектуре 2050 года также была функция безопасности, при которой нераспознанный код операции всегда приводил к остановке. Поскольку у 2050-го была полноразмерная передняя панель, вы могли затем использовать ее, чтобы попытаться выяснить, что сломалось. Поскольку регистр X всегда содержал текущий идентификатор процесса, это обычно было довольно просто.

Не было ни сегментации памяти, ни защиты, поэтому было вполне возможно, что процесс испортит любой другой процесс, находящийся в настоящее время в памяти, или что-то еще. в системной области.

Пока так согласованно для эпохи (конец 70-х).

Поскольку эта конкретная система имела общую память между двумя процессорами, конфигурация системы поместила системные таблицы в общую память, чтобы позволить одному ЦП запускал и останавливал процессы в другом без необходимости проходить через какой-либо изящный безопасный интерфейс.

К сожалению, это также позволило дикому процессу одного ЦП повредить таблицы для другого ЦП, так что один ЦП мог благополучно вывести из строя другой. Если это произошло, то, что работало в отказавшем процессоре, не имело никакого отношения к фактической ошибке. Тем временем другой процессор успешно продолжал работу, так что не было возможности определить, вызвал ли он проблему.

Излишне говорить, что это обеспечило несколько проблем, которые трудно исправить!

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

Это помогло мне прояснить довольно много взаимных проблем с процессором ...

Это помогло мне прояснить довольно много взаимных проблем с процессором ...

Это помогло мне прояснить довольно много взаимных проблем с процессором ...

В настоящее время я учусь в университете, и самая сложная ошибка, с которой я столкнулся, была в классе программирования. В предыдущих двух семестрах мы просто написали весь свой код. Но на третий семестр профессор и преподаватель должны были написать половину кода, а мы должны были написать вторую половину. Это должно было помочь нам научиться читать код.

Нашим первым заданием на тот семестр было написать программу, имитирующую расщепление генов ДНК. В принципе, мы просто должны были найти подстроку в более крупной и обработать результаты. Видимо, профессор и Т.А. были заняты на той неделе и отдали нам свою половину кода, не имея еще своей полной реализации. У них не было времени написать вторую половину, чтобы выступить в роли решения. Их половина компилировалась, но без полного решения, закодированного в коде, у них не было возможности его протестировать. Нам сказали не изменять код профессоров . У всех в классе была точно такая же ошибка, но все мы все равно предполагали, что совершаем одну и ту же ошибку.

Программа жужжала гигабайты памяти, а потом кончалась и разбивалась. Мы (ученики) все предполагали, что в нашей половине кода должна быть какая-то непонятная утечка памяти. Все в классе две недели прочесывали код и прогоняли его через отладчик снова и снова. Наш входной файл представлял собой строку размером 5.7 Мб, и мы находили в ней сотни подстрок и хранили их. Профессорско-преподавательский код использовал это.

myString = myString.substr(0,pos);

Видишь проблему? Когда вы присваиваете строковую переменную собственной подстроке, память не перераспределяется. Это лакомый кусочек информации, который никто не знал (ни профессор, ни ТП). Поэтому myString имел 5.7 Мб выделенной памяти только для хранения нескольких байт актуальных данных. Это повторялось сотни раз, что приводило к массовому использованию памяти. Я потратил две недели на эту проблему. Первую неделю я проверял свой код на утечку памяти. В своем разочаровании я, наконец, пришел к выводу, что утечка должна быть у половины профессора/Телевика, поэтому вторую неделю я потратил на проверку их кода. Но даже тогда я так долго искал, потому что технически это была не утечка. В конце концов, все распределения были освобождены, и программа работала нормально, когда наши входные данные составляли всего дюжину килобайт. Единственная причина, по которой я нашел это, была в том, что я послал психопата с ума и решил проанализировать каждую последнюю переменную; даже временную отбрасывающую вещь. Также я потратил много времени, проверяя, сколько символов на самом деле было в строке, а не сколько было выделено. Я предположил, что об этом позаботится класс строк. Вот решение - изменение в одну строку, которое исправило неделями разочарований и заработало мне пятёрку по присваиванию за нахождение/исправление кода учителя.

myString.substr(0,pos).swap(myString);

Метод подкачки, действительно, заставляет перераспределять.

Однажды у меня была ошибка в приложении .NET, которая приводила к сбою CLR - да, CLR просто выйдет с ненулевым результатом и не будет никакой отладочной информации.

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

В конце концов я изменил код с:

int value = obj.CalculateSomething();

на

int value;
value = obj.CalculateSomething();

Не спрашивайте меня, почему, но это сработало.