Неожиданно быстро (всего за один рабочий день) получилось сделать нормальную поддержку .NET Framework 4.0 (реализован ICorProfilerCallback3 и используется ICorProfilerInfo3 + Enter3/Leave3/Tailcall3) в dotTrace 4.0, правда пока не совсем полноценную:
Обнаружил очередную приколку в .NET Profiling API - есть событие ObjectsAllocatedByClass, где в качестве одно из аргументов передается массив ClassID. Так вот, если вызвать GetClassIDInfo/GetClassIDInfo2 для этого массива, то можно получить ModuleID для которого тоже можно вызвать GetModuleInfo. Все будет хорошо до тех пор пока GC не произойдет во время выгрузки application domain. Вот тут-то и появится проблема - GetModuleInfo может вернуть CORPROF_E_DATAINCOMPLETE. Так в чем же дело?
В MSDN сказано, что при выгрузке домена все классы и функции этого домена становятся недействительными - мы уже знаем что это ложь: во время выгрузки происходят компиляции функций и выделения объектов из самого выгружаемого домена до получения первого ModuleUnloadStarted. Сбор же мусора начинается как раз после получения всех ModuleUnloadStarted. Соответственно объекты из уже выгруженных модулей попадают в статистику GC. Занавес!
Как это однако приятно увидеть, что результатом твоего труда пользуются в компании Microsoft. Смотреть тут! Для тех кто не в теме: стектрейсы сделаны моим детищем - JetBrains dotTrace 3.1.
Ну вот, облизанный со всех сторон код рушится на моих глазах: RuntimeThreadSuspended и RuntimeThreadResumed оказывается могут вызываться из произвольного треда, а не только из того, что указан в аргументе. Получается, что повсеместно используемый TlsGetValue() именно в этих функциях со свистом пролетает мимо кассы. До сего момента я считал, что этим страдала только ThreadDestroyed, но там я выкрутился...
P.S. Иногда полезно быть параноиком и маниакально проверять в коде казалось бы очевидные вещи.
P.P.S. Если вы пользуетесь остановкой треда посредством DoStackSnapshot, то будьте готовы также получать и корректно обрабатывать RuntimeThreadSuspended и RuntimeThreadResumed.
Занимаясь инструментацией я пришел к выводу, что очень полезным является создание некой области на стеке функции для внутренних нужд профайлера. Для этого категорически необходимо создать структуру нужного размера. Увы, stackalloc не подходит так как требует довольно много накладных расходов и особенно под x64. Попытка использовать свой модуль с уже скомпилированными структурами во время работы профайлера приводит к зависанию во время загрузки оного. Поэтому пришлось в каждый модуль профилируемой программы эмитировать необходимую структуру.
Теперь о важном. Первое, что необходимо сделать - это найти mdAssemblyRef для mscorlob.dll и найти/создать mdTypeRef для System.ValueType - это необходимо, так как любая структура обязана иметь в качестве базового класса System.ValueType. Важно также чтобы наша структура имела атрибуты tdNotPublic, tdSequentialLayout, tdClass, tdSealed, tdBeforeFieldInit. И не забудьте установить необходимой вам class layout. Результатом всех этих действий будет mdTypeDef, который нужно засунуть в LocalVarSig.
Кстати в эту же структуру можно записывать (опять же с помощью той же инструментации) информацию о самой функции для профайлера - ну там statement count или еще что-нибудь нужное.
Единственная инструкция которая позволяет вызывать native код из IL есть calli. Возникает вопрос как нужно написать прототип функции на C++ для того чтобы передать аргументы из managed кода.
Для платформы x86 требуется чтобы функция была fastcall - первые два аргумента (те что передаются через регистры ECX и EDX) совпадают, а вот те аргументы которые лежат на стеке болжны быть описаны в обратном порядке (смотри MSDN x86 calling conversion а также Microsoft specific ECMA-335 Partition II 15.5.6.1). Привожу пример:
void fastcall MyOwnCallback(int arg0, int arg1, int arg4, int arg3, int arg2);
С платформой x64 еще проще используется стандартный calling conversion (смотри MSDN x64 calling conversion).
Как жаль, что MSDN теперь пишут так халтурно, лучше бы сделали нормальную документацию, а не переводили это дерьмо на кучу языков отличных от английского. И вот я снова вляпался: есть такая функция SetILInstrumentedCodeMap() в качестве 4-ого аргумента у которой должен быть массив COR_IL_MAP. Нигде в MSDN не сказано, что этот самый массив обязательно нужно выделать с помощью CoTaskMemAlloc(). Уродство, так как это есть существенное поведение функции, увы, не отраженное в документации.
P.S. Мне помогло разобраться только капание в Shared CLI.
Все вы наверное не раз пользовались классом System.Diagnostics.Process для запуска процессов из под .NET приложения. Но не все знают что если ProcessStartInfo.UseShellExecute установлен в false, то все handle исходного процесса наследуются дочерним, если конечно иное не указано для конкретного handle. Все вышесказанное касается в одинаковой мере и .NET Framework, и .NET Compact Framework.
P.S. Кстати, всем C++ разработчикам известная, функция fopen по умолчанию не уcтанавливает флаг _O_NOINHERIT. Начиная с Visual Studio 2005 добавлен новый параметр N, который собственно и должен выставлять этот флаг в fopen. Увы в Windows CE нет такой возможности. Более того так как lpSecurityAttributes в функции CreateFile должен быть всегда NULL, то и установить переменную bInheritHandle в SECURITY_ATTRIBUTES тоже невозможно.
a(x => b().c(x));и
a(b().c);В какой момент произойдет NullReferenceException для каждого из вариантов, если b() всегда возвращает null?
bool WildcardCompare(LPCWSTR pFilter, LPCWSTR pString)
{
while (*pString && *pFilter != L'*')
{
if (*pFilter != *pString && *pFilter != L'?')
return false;
++pFilter;
++pString;
}
LPCWSTR pBaseFilter;
LPCWSTR pBaseString;
while (*pString)
{
if (*pFilter == L'*')
{
if (!*++pFilter)
return true;
pBaseFilter = pFilter;
pBaseString = pString;
}
else if (*pFilter == *pString || *pFilter == L'?')
{
++pFilter;
++pString;
}
else
{
pFilter = pBaseFilter;
pString = ++pBaseString;
}
}
while (*pFilter == L'*')
++pFilter;
return !*pFilter;
}
Есть такой event JITInlining который спрашивает у профайлера будем ли в функцию A инлайнить функцию B. Обычно эти event'ы возникают между JITCompilationStarted и JITCompilationFinished. Что на самом деле довольно логично: начали компиляцию, проинлайнили чего-нибудь, закончили компиляцию. Но вот, откуда ни возьмись, появляются независимые JITInlining без обрамления начала и конца компиляции. Поиследовав немного этот вопрос я нашел, что token функции в которую производятся инлайны всегда 0x06000000 - что на самом деле говорит нам, что токена у такой функции нет. Token класса такой же пустой - 0x02000000. Выводы? А их нет - это косяк, хотя и довольно безобидный.
Еще косячок посерьезнее - после event'a AppDomainShutdownStarted могут происходить компиляции finalizers в application domain для которого был вызван AppDomainShutdownStarted. С другой стороны в документации написано, что id application domain стабилен и правилен только до окончания вызова AppDomainShutdownStarted.
str.swap(std::wstring());Естественно все работает и для std::wstring.
size_t NOD(size_t a, size_t b)
{
while (a != 0 && b != 0)
if (a >= b)
a = a % b;
else
b = b % a;
return a + b;
}
ThreadPool.QueueUserWorkItem(state => client.DownloadStringAsync(uri), null);
Задача не так проста как кажется с первого взгляда - я потратил несколько часов чтобы ее решить. Итак, нам нужно сгенерировать из MSBuild'а файлик с расширением vsprops и примерно таким содержимым:
<?xml version="1.0"?> <visualstudiopropertysheet ProjectType="Visual C++" Version="8.00" Name="my project name" OutputDirectory="my output path"> </VisualStudioPropertySheet>
Далее мы должны передать имя этого файлика в таску VCBuild через параметр Override. При вызове дочернего MSBuild нужно использовать Properties прмерно такого выда:
<msbuild Projects="My.sln" Targets="Rebuild" Properties="$(BuildSolutionProperties);Configuration=Release;Platform=Win32;VCBuildOverride=My.vsprops;" />
Вот собственно и все...
Для начала нужно поставить .NET Framework 1.1. Теперь мы должны создать target файл, который мы затем подключим в csproj. Проблема в том, что набор опций csc.exe для .NET 1.1 немного не совпадает с набором опций для .NET 3.5. Поэтому некоторые опции задавлены. Вот пример такого файла с именем Csc11.Targets:
<?xml version="1.0" encoding="utf-8"?>
<!-- Included into the project files right after MS common targets. -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<PropertyGroup>
<UseHostCompilerIfAvailable>False</UseHostCompilerIfAvailable>
<TargetFrameworkVersion>v1.1</TargetFrameworkVersion>
<ErrorReport></ErrorReport>
<NoWarn>1591</NoWarn>
<AssemblyOriginatorKeyFile></AssemblyOriginatorKeyFile>
<CscToolPath>$(WinDir)\Microsoft.NET\Framework\v1.1.4322</CscToolPath>
</PropertyGroup>
</Project>
Далее модифицируем csproj. Внимание, наш импорт должен быть последним в списке импортов!
<Import Project="Csc11.Targets" />
На этом все должно заработать. После модификации файла csproj, при загрузке, вам могут задать вопрос о том что ваш проект имеет внешние ссылки. Ответить нужно это вопрос нужно так:
Зачем я публикую эту информацию? Все просто, когда она мне понадобилась я потратил кучу времени, чтобы ее найти в достаточно полном объеме.
Сразу оговорюсь, что OS семейства Windows 95/98/Milenium/NT 3.5x/NT 4.0 я не рассматриваю - так как у меня есть причины считать, что эти OS уже не встречаются сегодня достаточно широко.
Теперь несколько комментариев к аргументам функции. processorArchitecture получается при помощи native вызова GetNativeSystemInfo(). GetVersionEx() дает нам majorVersion, minorVersion, buildNumber, csdVersion, suiteMask и productType. GetProductInfo() - vistaProductType. А флаги IsXPTabletPC, IsXPMediaCenter, IsXPStarter, Is2K3ServerR2 - при помощи нескольких вызовов GetSystemMetrics() с соответствующими аргументами.
Это достаточно важное число и оно по сути эквивалентно номеру ServicePack в обычных Windows. Найти его можно в реестре HKEY_LOCAL_MACHINE\SYSTEM\Versions|Aku
По роду своей деятельности я занимаюсь в том числе и инструментацией IL. Задача состоит в инжекции в оригинальный IL callback'ов: в начало каждого стейтмента (вынимается из PDB) и в каждую точку выхода из функции. С точками возврата есть две проблемы: префикс tail. и throw/rethrow.
Первый в реальных программах практически не встречается, но при встрече гарантирует автору инструментатора головную боль. По спецификации после префикса tail. должен следовать call/calli/callvirt, а после него обязательно ret. Все бы хорошо, но по спецификации на ret разрешен переход (и какой урод это придумал). Объясню более подробно - вы должны проинструментировать все точки выхода из программы, с одной стороны вы не имеете права вставлять свои команды между tail., call/calli/callvirt и ret, а с другой стороны вы должны вставить перед командой ret код, в случае перехода на этот самый ret. Выход один - править структуру метода...
Второй вариант коварнее. При кидании exception'а невозможно на основании только кода метода понять куда нас этот exception занесет. Мы можем остаться в том же самом методе - в обработчике exception, а можем вылететь из метода как пробка из бутылки на несколько функций наверх по стеку. К чему я все это говорю? А к тому - слава великому Аллаху, что как минимум одному сотруднику компании Microsoft пришла в голову мысль добавить немного жизненно нужных event'ов в профайлерное API. Особый интерес представляют: ExceptionUnwindFunctionEnter, ExceptionUnwindFunctionLeave и ExceptionCatcherEnter.
И еще, в свете вышесказанного, флаги COR_PRF_MONITOR_EXCEPTIONS, COR_PRF_MONITOR_ENTERLEAVE и COR_PRF_MONITOR_CODE_TRANSITIONS должны всегда устанавливаться вместе. Последний флаг - это вообще магия без него нет метаданных в памяти для mscorlib и нет 90% Enter/Leave/Tailcall или Enter2/Leave2/Tailcall2 для managed кода.
А напоследок граф переходов обработчика exception так сказать для полноты картины:
.png)
.png)
И снова .NET Compact Framewok! Читаем документацию для методов System.Type.InvokeMember. Из прочитанного видим, что эти методы поддерживаются .NET Compact Framewok (MSDN VS2008) - есть значек .gif)
рядом с методом.
Используем в приложении, запускаем и ... получаем NotSupportedException. Берем .NET Reflector и с удивлением выясняем, что метод вообще не реализован! Другими словами работающей рефлексии в .NET Compact Framewok v3.5.7283 вообще нет!
P.S. После начинаем вчитываться в документацию и случайно видим такую строчку в одной из двух доступных реализаций сего метода: NotSupportedException - The .NET Compact Framework does not currently support this method. Лезем в MSDN в и-нете - а вот там уже все нормально.