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) всегда в границах массива и был всегда меньше значения его текущей верхней границы. Но это решение ведёт к непроизводительным затратам процессорного времени.
Другое решение состоит в копировании необходимых данных во временный массив, безопасную работу уже с ним и, наконец, копирование данных обратно в целевую структуру данных. При этом желательно делать блокировку целевой структуры данных на время всех операций от изменения данных (и размера целевого массива) другими сервисами.
Сторонник WinDbg+SOS, но только не на машине, где установлена полноценная IDE со всеми нужными настройками =). А так очень здорово, спасибо за расследование. Всё таки приятно читать чьё-то другое, чем самому ковыряться в дампе ;-).
Sign up to leave a comment.
Дело о пропавшем индексе