Comments 21
Я, возможно, что-то не понял, но расскажите, а зачем так страшно? зачем уходить в ассемблер? первый фреймворк не поддерживает скачивание кода?
weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx
weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx
weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx
weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx
Теперь я люблю GUI-дебаггеры ещё больше…
бррр… я за Reflector + VS .Net source
Разбирать дотнет до ассемблерного кода это крайне сурово.
Исправленна ошибка это всегда приятно. Вот интересно, в какую сумму работодателю вылились такое глубокое копание, ну или проще говоря: сколько человеко-часов ушло на дизассамблирование?
А еще говорят, что C# легок в использовании и освоении…
Описанный автором детектив можно было и аналитически расследовать, по собственному коду, вообще не пытаясь дизассемблировать сборки и т.д. (хотя признаю, stacktrace не самый понятный).
Статья интересна, скорее, фактом подобной возможности, разобрать всё до регистров :)
К тому же, работа с нетипизированными датасетами и databiding — не самые очевидные вещи как раз из-за того, что и было описано — в неожиданные моменты могут обработчики зашевелиться, о которых сразу и не подумаешь, что они в принципе могут быть задействованы. И к C# как к языку, все эти ужасы имеют, скорее, косвенное отношение.
Статья интересна, скорее, фактом подобной возможности, разобрать всё до регистров :)
К тому же, работа с нетипизированными датасетами и databiding — не самые очевидные вещи как раз из-за того, что и было описано — в неожиданные моменты могут обработчики зашевелиться, о которых сразу и не подумаешь, что они в принципе могут быть задействованы. И к C# как к языку, все эти ужасы имеют, скорее, косвенное отношение.
Из статьи понятно, что простое присваивание int count = this.shadowIndexes.Count; и последующее выполнение в цикле конструкции ((Index)this.shadowIndexes[i]).Reset(); даёт побочный эффект:
переменная count не может оставаться константой в цикле, так как есть вероятность изменения массива shadowIndexes в любую сторону, отчего и будут происходить глюки.
Одно из решений проблемы: преобразовать цикл так, чтобы счётчик (переменная i) всегда в границах массива и был всегда меньше значения его текущей верхней границы. Но это решение ведёт к непроизводительным затратам процессорного времени.
Другое решение состоит в копировании необходимых данных во временный массив, безопасную работу уже с ним и, наконец, копирование данных обратно в целевую структуру данных. При этом желательно делать блокировку целевой структуры данных на время всех операций от изменения данных (и размера целевого массива) другими сервисами.
переменная count не может оставаться константой в цикле, так как есть вероятность изменения массива shadowIndexes в любую сторону, отчего и будут происходить глюки.
Одно из решений проблемы: преобразовать цикл так, чтобы счётчик (переменная i) всегда в границах массива и был всегда меньше значения его текущей верхней границы. Но это решение ведёт к непроизводительным затратам процессорного времени.
Другое решение состоит в копировании необходимых данных во временный массив, безопасную работу уже с ним и, наконец, копирование данных обратно в целевую структуру данных. При этом желательно делать блокировку целевой структуры данных на время всех операций от изменения данных (и размера целевого массива) другими сервисами.
UFO just landed and posted this here
Сторонник WinDbg+SOS, но только не на машине, где установлена полноценная IDE со всеми нужными настройками =). А так очень здорово, спасибо за расследование. Всё таки приятно читать чьё-то другое, чем самому ковыряться в дампе ;-).
Sign up to leave a comment.
Дело о пропавшем индексе