Подтвердить что ты не робот

Неверные номера строк в трассировке стека

Проблема

На нашем веб-сайте ASP.net я продолжаю вводить неправильные номера строк в стеках следов исключений. Я говорю о нашей живой среде. Кажется, что существует шаблон: трассировка стека всегда будет указывать на строку, содержащую метод закрытия фигурных скобок.

Пример:

public class Foo
{
    public void Bar()
    {
        object someObject = null;
        someObject.ToString();
     /*
          arbitrarily more lines of code
     */
     } // this line will be the one that the stack trace points to
}

Подробнее

  • Чтобы быть ясным: это происходит не только для некоторых методов (методов), это происходит для каждого исключения, которое мы регистрируем. Поэтому я бы исключал оптимизацию (JIT) здесь, что может привести к тому, что номера строк кажутся случайным образом отключенными. Меня беспокоит, что неправильные номера строк, похоже, постоянно указывают на закрывающиеся фигурные скобки содержащего метода.

  • Обратите внимание, что перед .net 4.6 на самом деле была ошибка в структуре, так что если вы скомпилировали таргетинг x64, это произойдет именно так. Однако Microsoft подтвердила, что это исправлено. Также, используя для этого минимальное примерное приложение, подтверждается их требование. Но по какой-то причине это все еще происходит на веб-серверах.

  • Это еще больше озадачивает меня, что этого не происходит в нашей среде тестирования и разработки. Испытательные и живые системы аналогичным образом настроены. Единственное реальное различие заключается в том, что в настоящее время мы работаем под управлением Windows Server 2012, а в тестовой системе мы все еще используем Windows Server 2008.

Что я проверил

  • Файлы pdb действительны (проверены с помощью chkmatch)
  • Оптимизация кода времени компиляции не является проблемой.
  • Вышеупомянутая ошибка в .net до 4.6 не может быть воспроизведена с минимальным примером
  • Версия .NET точно такая же
  • Сборка происходит из одного и того же развертывания script

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

4b9b3361

Ответ 1

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

Ответ 2

Оптимизация компиляции, а также оптимизация времени выполнения могут изменить фактическое выполнение, а также сконфигурированную информацию стека вызовов. Поэтому вы не можете серьезно относиться к номерам.

Более подробную информацию можно найти в таких сообщениях, как Scott Hanselman's: Release НЕ ОТКЛОНЯТ: 64-битные оптимизации и метод С# Вложение в выпуске сборки стеков вызовов.

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