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

В двух словах: утечки памяти .

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

Это похоже на классика Heisenbug. Минута Вы распознаете его, Вы сразу, проходит, ища неинициализированные переменные или складывает граничное повреждение.

У меня был фрагмент кода Delphi, в котором выполнялась длинная процедура обработки, обновлявшая индикатор выполнения по мере необходимости. Код прекрасно работал в 16-битной Delphi 1, однако, когда мы обновились до Delphi 2, процесс, который занимал 2 минуты, внезапно занял около часа. это вызвало проблему, для каждого изменения мы проверяли количество записей с помощью table1.recordcount, в delphi 1 это работало нормально, но, похоже, в более поздних версиях delphi вызов table.recordcount для таблицы dbase берет копию таблицы, подсчитывающую записи и возвращает сумму, вызывая ее при каждом изменении нашего прогресса, вызывая загрузку таблицы из сети с каждым повторением и подсчетом.

Я не могу представить, как они кодировали это: Нельзя назначить IP-адрес 127.0.0.1 адаптеру обратной связи, поскольку он является зарезервированным адресом для устройств обратной петли - Microsoft® Windows XP PROFESSIONAL

Однажды я удалил PHP. Вручную. Много ошибок исправлено одним движением ...

Это была небольшая ошибка в Rhino (интерпретатор Javascript в Java), которая приводила к сбою одного сценария. Это было трудно, потому что я мало знал о том, как будет работать интерпретатор, но мне пришлось прыгнуть туда, чтобы исправить ошибку как можно быстрее, ради другого проекта.

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

Я разобрал (очищенный) лог-файл рабочего прогона от пробивного прогона, чтобы увидеть, с какой точки они впервые начали расходиться Повторно запустив и добавив множество точек останова, Я нашел свой путь к цепочке событий, которые привели к провалу. Где-то там была строка кода, которая, если писать немного по-другому, решала проблему! (Это было что-то очень простое, например, nextNode () должен возвращать null вместо IndexOutOfBounds.)

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

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

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

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

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

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

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

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

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

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

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

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

У нас был сервер RMI, работающий в командной строке DOS Кто-то «выбрал» окно, что приостановило процесс

Исправить это было довольно просто ... нажмите Enter.

Это был довольно мучительный день ...

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

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

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

Однако кое-что об отладчике '

Несколько лет назад я несколько дней пытался отслеживать вниз и исправьте небольшую ошибку в dbx, текстовом отладчике в AIX. Я не помню точную ошибку. Сложно было то, что я использовал установленный dbx для отладки dev-версии dbx, над которой я работал. Было очень сложно отслеживать, где я был. Более чем однажды я готовился уйти на этот день и дважды выходил из dbx (версия для разработчиков и установленная версия) только для того, чтобы видеть, что я все еще работаю внутри dbx, иногда на два или более уровня «глубже».

-
bmb

Сбой в DLL, загруженной из службы. Вызывается выключением системы.

Ошибка была легко исправлена, но потребовалось около недели - и много разочарований - чтобы найти.

Необъяснимые тайм-ауты SQL Server и периодическая блокировка

У нас была проблема, из-за которой наши пользователи теряли время ожидания без всякой причины. Некоторое время я наблюдал за SQL Server и обнаружил, что время от времени происходит много блокировок. Так что мне нужно найти причину этого и исправить.

Если происходила блокировка, значит, где-то в цепочке сохраненных вызовов процедур должны быть исключительные блокировки…. Правильно?

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

Я искал какие-либо инструкции UPDATE или INSERT…. Их не было (за исключением временных таблиц, которые имели только объем хранимой процедуры, поэтому они не учитывались. )

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

A. Если вы используете SELECT INTO для создания своей временной таблицы, то SQL Sever устанавливает блокировки на системные объекты. В нашей процедуре getUserPrivileges было следующее:

            --get all permissions for the specified user
            select   permissionLocationId,
                permissionId,
                siteNodeHierarchyPermissionId,
                contactDescr as contactName,
                l.locationId, description, siteNodeId, roleId
            into #tmpPLoc
            from vw_PermissionLocationUsers vplu
                inner join vw_ContactAllTypes vcat on vplu.contactId = vcat.contactId
                inner join Location l on vplu.locationId = l.locationId
            where  isSelected = 1 and
                contactStatusId = 1 and
                vplu.contactId = @contactId

Процедура getUserPrivileges вызывается при каждом запросе страницы (она находится на базовых страницах). Она не была кэширована, как вы могли ожидать. Это не похоже, но приведенный выше SQL ссылается на 23 таблицы в предложениях FROM или JOIN. Ни на одной из этих таблиц нет подсказки «with (nolock)», поэтому на это уходит больше времени, чем следовало бы. Если я удалю предложение WHERE, чтобы получить представление о количестве задействованных строк, оно вернет 159 710 строк, а выполнение займет от 3 до 5 секунд (в нерабочее время, когда на сервере больше никого нет).

Итак, если эта сохраненная процедура может только запускаться по одному из-за блокировки, и он вызывается один раз на страницу, 1. Используйте кэширование на уровне сеанса, поэтому оно вызывается только один раз за сеанс. 2. Замените SELECT INTO кодом, который создает таблицу с помощью стандартных операторов DDL Transact-SQL, а затем используйте INSERT INTO для заполнения таблицы. 3. Ставьте «with (nolock)» на все, что связано с этим вызовом.

B. Если у сохраненной процедуры getUserPrivileges не было достаточно проблем для вас, позвольте мне добавить: она, вероятно, перекомпилируется при каждом вызове. Таким образом, SQL Server получает блокировку COMPILE при каждом вызове.

Причина его перекомпиляции заключается в том, что создается временная таблица, а затем из нее удаляется множество строк (если переданы @locationId или @permissionLocationId). Это приведет к перекомпиляции сохраненной процедуры в следующем SELECT (да, в середине выполнения сохраненной процедуры). В других процедурах я заметил оператор DECLARE CURSOR, оператор SELECT которого ссылается на временную таблицу - это вызовет тоже перекомпилируйте.

Для получения дополнительной информации о перекомпиляции см .: http://support.microsoft.com/kb/243586/en-us

Исправление: 1. Опять же, используйте кеширование гораздо реже, чем раньше. 2. Применяйте фильтрацию @locationId или @permissionLocationId в предложении WHERE во время создания таблицы. 3. Замените временные таблицы табличными переменными - они приводят к меньшему количеству перекомпиляций.

Если что-то работает не так, как вы ожидаете, вы можете потратить много времени, глядя на что-то, не пытаясь понять, что не так.

Я исправляю чью-то ошибку кодом ниже :

private void foo(Bar bar) {
    bar = new Bar();
    bar.setXXX(yyy);
}

Он ожидал, что бар будет изменен за пределами foo!