Я начал переводить Интеграцию на VS 2008. Сейчас в SVN лежат исходники которые компилируются под VS 2008 и новым SDK (к ней). Однако при попытке создать или открыть проект студия валится "без объявления войны", т.е. без разумной информации.
По всей видимости происходит переполнение стека вызванное зацикливаением какого-то кода в Интеграции. Но переполнение стека не перехватывается когда код выполняется под студией. Это конечно только предположение, но в прошлые разы такое поведение было именно при переполнении стека.
Отлов подобные баги крайне трудно ловить. Нужно ставить брэйкпоинты в коде интеграции и искать код который приводит к зацикливанию. Делать это можно только перебором.
По сему прошу все у кого есть время и силы помочь в поиске этого вылета.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я начал переводить Интеграцию на VS 2008. Сейчас в SVN лежат исходники которые компилируются под VS 2008 и новым SDK (к ней). Однако при попытке создать или открыть проект студия валится "без объявления войны", т.е. без разумной информации.
даже окошко с исключением не вываливается?
а если запустить под дебаггером?
__>>а если запустить под дебаггером? VD>Никак. Просто вылезает окошко с надписью, что приложение будет закрыто. Ни тебе стэкрэса, ни возможности запустить отладку.
не понял.
я имею ввиду, запустить дебаггер, а из него уже запустить то, что падает. не наоборот.
в худшем случае, дебаггер остановится на функции TerminateProcess.
Здравствуйте, VladD2, Вы писали:
VD>Никак. Просто вылезает окошко с надписью, что приложение будет закрыто. Ни тебе стэкрэса, ни возможности запустить отладку.
Я так делал: запускал две студии, из одной делал attach to process, явно указывал native+managed, потом в отлаживаемой загружал немерлёвый проект.
Явное указание native+managed позволяет видеть оба стека — и управляемый и обычный.
Сами проекты открываются, редактируются и компилируются без проблем и отладчик тоже работает (проверено на довольно больших проектах). Куда-то ушла менюшка Nemerle и AST Tool Window...
Валится код заполнения комбов в Navigation Bar. Абсолютно та же проблема была и в моей завечернаколенкеделанной интеграции с VS2008 (я даже про это писал), но запарка сейчас такая что я и в выходные нормально позаниматься немерлом не могу
Перешёл на твою версию интеграции, для работы просто отключил Navigation Bar. Надеюсь за субботу смогу выложить патч который исправит ситуацию, т.к. у меня в студии стактрэйс с переполнением стека почему-то видно.
Да, в некоторых проектах пришлось удалить и заново поставить рефернсы на Nemerle.dll и Nemerle.Macros.dll, при том что я и NGen'ом прошёлся и в GAC поставил, раньше при обновлениях версии компилятора такого делать не надо было, х-з почему...
Забыл написать в предыдущем посте. Версия из SVN не компилируется -- в SVN нехватает файла Nemerle.VsIntegration\Utils.cs и проперти VSRegistry_RegistryRoot в нём. Для компиляции я взял код этой проперти из своей версии интеграции но выкладывать файл целиком не стал -- вдруг ты ещё что-то менял в нём. Выложи плиз.
Если кто-то будет собирать до того как Влад обновит файл — код этой проперти, который работал у меня:
public static RegistryKey VSRegistry_RegistryRoot
{
get
{
Microsoft.VisualStudio.Shell.Interop.ILocalRegistry3 ILocalRegistry3 =
Microsoft.VisualStudio.Shell.Package.GetGlobalService(typeof(Microsoft.VisualStudio.Shell.Interop.SLocalRegistry))
as Microsoft.VisualStudio.Shell.Interop.ILocalRegistry3;
string root = null;
ILocalRegistry3.GetLocalRegistryRoot(out root);
if(root == null)
return null;
return Registry.LocalMachine.OpenSubKey(root);
}
}
Здравствуйте, Блудов Павел, Вы писали:
БП>Я так делал: запускал две студии, из одной делал attach to process, явно указывал native+managed, потом в отлаживаемой загружал немерлёвый проект. БП>Явное указание native+managed позволяет видеть оба стека — и управляемый и обычный.
Помогло! Правда, на моей рабочей машине почему-то на запускается языковый пакет (открывается C#-пный редактор вместо Немерлового). Но дома я поймал ошибку. Оказалось циклит (т.е. как я и предпологал, переполнение стека) код в комбах (МС-ный):
// Omitting any of the following operator overloads
// violates FxCop rule: IComparableImplementationsOverrideOperators.
/// <include file='doc\CodeWindowManager.uex' path='docs/doc[@for="DropDownMember.Operator=="]/*' />public static bool operator ==(DropDownMember m1, DropDownMember m2) {
if (null == m1) {
return (null == m2);
}
return m1.Equals(m2);
}
В общем, душить надо этих индусов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>// Omitting any of the following operator overloads
VD>// violates FxCop rule: IComparableImplementationsOverrideOperators.
VD>/// <include file='doc\CodeWindowManager.uex' path='docs/doc[@for="DropDownMember.Operator=="]/*' />
VD>public static bool operator ==(DropDownMember m1, DropDownMember m2) {
VD> if (null == m1) {
VD> return (null == m2);
VD> }
VD> return m1.Equals(m2);
VD>}
VD>
VD>В общем, душить надо этих индусов.
Открылись странные осбтоятельства. Этот код содержится в сборке Microsoft.VisualStudio.Package.LanguageService.dll, но к проекту подключена сборка Microsoft.VisualStudio.Package.LanguageService.9.0.dll (обе из каталога %VisualStudioIntegration%\Common\Assemblies\).
Так вот, почему подцепляется не та сборка я пока понять не могу. Но если зацепить правишьную версию, то все должно заработать как надо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>// Omitting any of the following operator overloads
VD>// violates FxCop rule: IComparableImplementationsOverrideOperators.
VD>/// <include file='doc\CodeWindowManager.uex' path='docs/doc[@for="DropDownMember.Operator=="]/*' />
VD>public static bool operator ==(DropDownMember m1, DropDownMember m2)
VD>
Я тут вдруг вспомнил, что знал об этой проблеме. И тупо заменил у себя на машине на
// Omitting any of the following operator overloads
// violates FxCop rule: IComparableImplementationsOverrideOperators.
/// <include file='doc\CodeWindowManager.uex' path='docs/doc[@for="DropDownMember.Operator=="]/*' />public static bool operator ==(DropDownMember m1, DropDownMember m2) {
return Equals(m1, m2);
}
После чего NavigationBar перестал вылетать с NullReferenceException если m1 == null.
Индусам я об ошибке отписал, они добавили проверку на null. Но похоже и этого мало.
Слушай, может тупо выкинуть все эти операторы?
Здравствуйте, VladD2, Вы писали:
VD>Открылись странные осбтоятельства. Этот код содержится в сборке Microsoft.VisualStudio.Package.LanguageService.dll, но к проекту подключена сборка Microsoft.VisualStudio.Package.LanguageService.9.0.dll (обе из каталога %VisualStudioIntegration%\Common\Assemblies\).
VD>Так вот, почему подцепляется не та сборка я пока понять не могу. Но если зацепить правишьную версию, то все должно заработать как надо.
Обманулся я.
На самом деле дебильный код "рекурсивной проверки на null" находится таки в Microsoft.VisualStudio.Package.LanguageService.9.0.dll, а в Microsoft.VisualStudio.Package.LanguageService.dll вообще проверок нет.
В общем, принял решение полностью заменить реализацию TypeAndMemberDropdownBars и DropDownMember воспроизведя их кишки в NemerleTypeAndMemberDropdownBars и NemerleDropDownMember соответственно. Надеюсь — это поможет.
ЗЫ
Вообще держать столь тупорылых программистов и при это не тестировать все и вся — это очень чревато. Я не понимаю на что там в МС надеятся. Это же надо было "исправить" ошибку так, что вместо нервирующих, но не смертельных исключений NullReferenceException начать получат переполнение стека. Ну, хоть 5 грам мозга ведь должно было быть у того кто это сделал? Неужели трудно протестировать исправления? Я уже не говорю о напряжении головного мозга.
А вообще, это от части ошибка которая появилась вследствии бездарного дизайна перегрузки операторов в дотнете и бердового правила, что при переопределении bool Equals(Object obj) надо переопределять и операторы сравнения. В результате с частотой достойной лучшего применения получаются вот такие перлы.
Повбывалбы! (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Блудов Павел, Вы писали:
БП>После чего NavigationBar перестал вылетать с NullReferenceException если m1 == null. БП>Индусам я об ошибке отписал, они добавили проверку на null. Но похоже и этого мало. БП>Слушай, может тупо выкинуть все эти операторы?
Код то в .VisualStudio.Package.LanguageService.9.0.dll. Так что или отказываться от ее использования или ничего не поправишь.
Я сделал проще. Переопределил все виртуальные методы и заменил всю раелизацию на собственную Сейчас в СВН лежт версиях где оба класса переопределены и в них все сдублировано.
Вылеты я вроде обошал, но пока комбы как следует не работают (не заполняются). Ну, да это уже мелочи. Будет время — доведу до работоспособности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
