Дело о пропавшем индексе

[habralan]

Я, возможно, что-то не понял, но расскажите, а зачем так страшно? зачем уходить в ассемблер? первый фреймворк не поддерживает скачивание кода?
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

[brainfucker]

при чём тут ассемблер? это байт код

[brainfucker]

А вообще спасибо, до этого не видел байт код .net очень интересно!

[YasonBy]

Теперь я люблю GUI-дебаггеры ещё больше…

[nchaly]

Windbg и есть GUI-debugger.

Вы, вероятно, имеете ввиду source-level дебагеры, windbg тоже source-level, только не для C#.

Кстати, я их тоже люблю еще больше.

[SynteZZZ]

weblogs.asp.net/nunitaddin/archive/2006/11/05/Debug-With-Reflector.aspx

[pieceofsummer]

Это, конечно, хорошо, но метание туда-сюда между окнами и по менюшкам напрягает, если честно.

Кроме того, отладки как таковой в рефлекторе нету — это что-то типа «куда я вообще попал?». А для отладки там такой же листинг.

[zabr]

бррр… я за Reflector + VS .Net source

[nchaly]

Я тоже за рефлектор, как видите.

И за .net source, хотя этого с первого взгляда не заметно.

Был бы у меня код, все бы заняло в десять раз меньше времени.

[Popik]

Разбирать дотнет до ассемблерного кода это крайне сурово.

[nchaly]

Спасибо майкрософту, и за .net, и за биндинг, и за датасеты. Верните три часа жизни, сволочи!

[Antipod]

Исправленна ошибка это всегда приятно. Вот интересно, в какую сумму работодателю вылились такое глубокое копание, ну или проще говоря: сколько человеко-часов ушло на дизассамблирование?

[nchaly]

3 часа.

[RazoR_Empire]

А еще говорят, что C# легок в использовании и освоении…

[DarkestMaster]

Описанный автором детектив можно было и аналитически расследовать, по собственному коду, вообще не пытаясь дизассемблировать сборки и т.д. (хотя признаю, stacktrace не самый понятный).

Статья интересна, скорее, фактом подобной возможности, разобрать всё до регистров :)

К тому же, работа с нетипизированными датасетами и databiding — не самые очевидные вещи как раз из-за того, что и было описано — в неожиданные моменты могут обработчики зашевелиться, о которых сразу и не подумаешь, что они в принципе могут быть задействованы. И к C# как к языку, все эти ужасы имеют, скорее, косвенное отношение.

[iZENfire]

Из статьи понятно, что простое присваивание int count = this.shadowIndexes.Count; и последующее выполнение в цикле конструкции ((Index)this.shadowIndexes[i]).Reset(); даёт побочный эффект:
переменная count не может оставаться константой в цикле, так как есть вероятность изменения массива shadowIndexes в любую сторону, отчего и будут происходить глюки.

Одно из решений проблемы: преобразовать цикл так, чтобы счётчик (переменная i) всегда в границах массива и был всегда меньше значения его текущей верхней границы. Но это решение ведёт к непроизводительным затратам процессорного времени.

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

[Frozik]

Сторонник WinDbg+SOS, но только не на машине, где установлена полноценная IDE со всеми нужными настройками =). А так очень здорово, спасибо за расследование. Всё таки приятно читать чьё-то другое, чем самому ковыряться в дампе ;-).

[craftsman]

эту статью не читали?
habrahabr.ru/blogs/net/52441/

[sgolubev]

Мы то читали, а вот вы нет.

Что-то мне подсказывает, что статья — выше :0)

[nchaly]

ух ты :)