Что делать, если поведение отладки отличается от обычного выполнения?

Question

У меня проблема с сеансами отладки. Моя программа очень хорошо выполняется в сеансе отладки, но если я запускаю обычный запуск, она ведет себя совершенно иначе.
Проблема в том, что я не могу сказать, почему он действует по-другому.

Одной из возможных причин является более медленное выполнение, потому что вы всегда должны нажимать F6 или около того.
Я попытался вставить Thread.sleep(1000);, но не получил инструкцию, вызывающую другое поведение.

Итак: Каковы подсказки, передовые практики, чтобы узнать, почему он действует так сильно в сеансах отладки?

Answer 1

Два решения:

a) Используйте отладчик бедного человека (печатайте на консоль) или используйте каркас журналирования. После возникновения ошибки проанализируйте вывод.

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

Answer 2

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

Answer 3

Я пытался проверить свои предположения, которые я сделал, и проверить их еще раз.

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

Мое личное решение было специфичным для Java. Java ClassLoader не загружает классы полностью, начиная с JDK 1.5. В сеансе отладки он должен быть загружен полностью. Таким образом, некоторые переменные не были хорошо инициализированы, а выходные данные отличались от нормального выполнения.
Эту причину очень трудно найти.

Answer 4

Очень сложно отлаживать многопоточные приложения.

Вы можете попытаться выполнить отладку, используя старую технику System.out.println вместо использования отладчика ... может быть, это позволит вам отлаживать, имея другое поведение, которое вы упомянули.

Маню

Answer 5

Я столкнулся с чем-то похожим.

Моя проблема: Set.iterator давал разные результаты в debug и run.

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

Answer 6

Примечание: многопоточность не требуется.

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

Иногда оценка значений изменяет их (например, чтение значений итератора).
Во-вторых, ваши «ложные» контрольные точки могут препятствовать параллелизму и условиям гонки.

Answer 7

Сначала проверь некоторые простые вещи. Получает ли сбойная версия те же аргументы командной строки? Или специальные переменные среды? Или идентификатор пользователя? Или какой-то другой фактор, который, как вы знаете, важен. Другими словами, вы действительно запускаете его с тем же вводом, как и раньше. Вылетает ли он все время? Вылетает ли он в одном и том же месте? Если вы можете подключить отладчик после сбоя, где он сломался, можете предоставить некоторые подсказки. Является ли недавнее изменение возможным виновником? Если это так, попробуйте удалить его и посмотреть, что произойдет.

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

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

Вот несколько отрывков из книги, которые могут помочь вам «отладить без отладчика».

Глава 5 «Отладка» из «Практики программирования»

9 правил из "9 обязательных правил для нахождения наиболее неуловимых проблем с программным и аппаратным обеспечением"

Удачи!