Так корень проблемы в неуправляемом коде, то и исправлять его придется. https://gitlab.eterfund.ru/gnivc/Mono_Nalog_Test/tree/master/TestTypeLoad2/bin/Debug -- тест для проверки. Выдает разный результат в Mono и Framework.
Функция описана в проекте \mono\msvc\libmonoruntime.vcxproj файл icall.c. При компиляции на выход получается libmonoruntime-sgen.lib. Пока не нашел место где в качестве аргумента ResolveEventArgs возвращается экземпляр со свойством Name, содержащим лишние, некорректные данные. Для меня осталось загадкой как используется данная .lib в дальнейшем. В установленных дистрибутивах ее не было обнаружено. Пока не нашел ответа на данный вопрос. Однако, удалось хорошо попрактиковаться в сборке компонентов Mono.
Есть предположение, что в mono/mono/metadata/assembly.c в функции mono_stringify_assembly_name происходит неправильное формирование информации о библиотеке в строку. Немного исправив библиотеку, добавив обработку различных случаев прихода информации о библиотеки, собрал без ошибок. Осталось теперь проверить на практике
Удалось разобратсья с тем, что именно в mono_stringify_assembly_name в assembly.c происходит неверное формирование имени библиотеки. Это удалось благодаря тому, что разобрался со сборкой Mono и с отладкой неуправляемого кода c++ с GDB на билдере 64. Немного поразбираясь и проведя тесты, данная реализации функции в тестовой программе выводит ту же строку, что и в Framework char* mono_stringify_assembly_name (MonoAssemblyName *aname) { const char *quote = (aname->name && g_ascii_isspace (aname->name [0])) ? "\"" : ""; return g_strdup_printf ( "%s%s%s, Version=%d.%d.%d.%d, Culture=%s, PublicKeyToken=%s%s", quote, aname->name, quote, aname->major, aname->minor, aname->build, aname->revision, aname->culture && *aname->culture? aname->culture: "", aname->public_key_token [0] ? (char *)aname->public_key_token : "", (aname->flags & ASSEMBLYREF_RETARGETABLE_FLAG) ? ", Retargetable=Yes" : ""); } Проблема: изменения заметны при запуске через gdb mono run ..exe, при запуске через mono проблема остается... Думаю, над организацией коммита в Mono Project
Готовил коммит для отправки в Mono и открытия ишью по данной проблеме, однако в последний момент обнаружил, что хоть на выход стала преходить по виду точно такая же строка, как и в Framework, но она не проходит проверку на сравнение строк из-за лишнего символа- пробела в конце. Для этого написал отдельную тест программу, которую потом приложу к ишью. Удалось найти проблемную строку из-за которой идет различие, но пока не удалось исправить данную проблему. Также читал о правилах и политике открытия ишью в проекте, почти все подготовил для корректной отправки
Проблему по выводу строки без лишнего пробела удалось решить на уровне mono_stringify_assembly_name. Однако, это не приемлемый результат. Так как, во-первых, в тестовой программе на запрос Type.GetType (..., библиотека <пробел>) и Type.GetType (..., библиотека) в Framework и Mono разные результаты : в Framework имя библиотеки обрезается в любом случае и пробел исчезает. В Mono оно так и остается, т.е. в assembly_name_to_aname в reflection.c (здесь набивается структура MonoAssemblyName, которая служит для отображения имени библиотеки) не происходит логика такой же обработки строки. Во-вторых, проблема оказывается более широкой, нежели считал ранее. Так, например, при передаче более полной информации о библиотеки, например: Type.GetType("System.ServiceModel.Configuration.DiagnosticSection, System.ServiceModel2, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") в обработчик события приходит строка имени библиотеки с дополнительной информацией, а при более скупом указании только имени - только имя. В Mono же один шаблон, который мы редактируем в вышеуказанной функции, это тоже требует более детальной обработки. Также, с очень большой, вероятность было обнаружено различие в поведении в Mono на windows и в wine на уровне win api- более подробно, после дальнейшего тестирования.
Сегодня сделал: 1. Доработал тесты по запросу Type.GetType (..) 2. Изменил assembly_name_to_aname так, чтобы при формировании структуры MonoAssemblyName поля типа uint16_t: major, minor, build, revision, arch по умолчанию инициализировались значением 65535, а не 0. Для того, чтобы различать значения переданные пользователем и автоматически инициализированные. Также поле cultural при нахождении в строке netural заполнялось именно этим значением. 3.Доработал mono_stringify_assembly_name так, чтобы была разница в выводе строки из-за разницы заполнения структуры передаваемой в функцию - MonoAssemblyName. Тестировал : большинство тестов идентично, но есть моменты для доработки
Сегодня разбирался в более обширных тонкостях формирования имени библиотеки. Особенно, в контексте того, что тесты 2,5,7,8,9,10,11,12 не выполняются в полном объеме. https://gitlab.eterfund.ru/gnivc/Mono_Nalog_Test/blob/master/LoadTypeTest/Program.cs Так для решения проблемы отбрасывания лишнего пробела(ов) при передаче в строке, исследовал функции _mono_reflection_parse_type, mono_reflection_parse_checked, mono_reflection_parse_type_checked. К сожалению, готового решения пока нет, но есть понимание, что нужно сделать и с чем: работа с символами строки (удаление). Также второй аспект, который возникает при других тестах (кроме 2) это то, что передаваемая строка не проходит проверки в _mono_reflection_parse_type
Сегодня удалось добиться значительно продвижения, так уже 11/12 тестов выполняются идентично. Так в assembly_name_to_aname добавил удаление пустых символов из строки, идущих в конце строки, так же в _mono_reflection_parse_type при обнаружении не нахождение запятой (при укороченном описании библиотеки), сделал проверку на удаление пустых символов в конце имени формирующийся библиотеки. В mono_stringify_assembly_name сделал все необходимые разветвления логики так, чтобы во всех случаях был выведен правильный результат. Что осталось : 1. Правильно оптимизировать и сделать "по-красоте" добавленный код, чтобы можно было отправлять его. 2. Осталась проблема при считывании параметра Culture=netural2, например, возможно стоит доработать логику, чтобы было как в FR. 3. Возможно добавить еще пару тестов. 4. Прогнать тесты Mono и сделать коммит.
Доработал по последнему замечанию про culture, потестировал, однако в системных тестах есть ошибки, хотя программа работает, надеюсь завтра разберусь и с причиной в них. Создал запрос на слияние : https://github.com/mono/mono/pull/19804 Также описал проблему : https://github.com/mono/mono/issues/19803 (добавить ярлыки и т.д. не могу почему-то)
1. На объявленную проблему в issue реакция положительная 2. На предложенный коммит - есть проблемы по прохождению сборки и тестов :( 3. Предложенные изменения надо переработать - сделать более подходящими (не использовать как флаг значения чисел и не делать сложное удаление пробелов, более правильную логику вывода на экран) Так в структуру MonoAssemblyName добавил поле типа gboolean has_version, которое будет сигнализировать о задании версии библиотеке. Уже сделал логику по заданию и проверке ее значения.
Сегодня продолжал работу над изменениями кода, была твердая уверенность, что переработанный код стал также работать, однако, это не совсем так. Из-за того, что параллельно занимался изучением не проходящих тестов, так тест pinvoke11 не проходит не в одной версии Моно (даже релизной), а при недоработанном коде аж 9 тестов показывают отрицательный результат. Также хотел полностью собрать Mono на win10, что ранее не удавалась, и где также не получилось собрать сегодня, хотя проделал всю последовательность действий (Cygwin - со всеми необходимыми пакетами, настройка путей и т.д). Зато стал гораздо лучше общаться с Git, из-за того, что много с ним работаю Вообщем, пока не похвастаться большими успехами, но я продолжаю работу
Закончил рефакторинг кода, учитывая пожелания высказанные ревьюверами. Переработал формировании строки с символами отвечающими за имя, культуру, версиии библиотеки. Дело было довольно непростое для меня как для новичка, надеюсь мой код понравится с точки зрения здравого смыла... Осталось рассмотреть тесты, так как поведение некоторых из них остается для меня большой загадкой
Из-за того, что предложенные мною изменения применяется не только в локальной цепочки по загрузке библиотеки и формированию строки с именем и другими параметрами, прежде всего версия и культура. Так при выполнении тестов : make check - около 9 тестов не проходят. Начал разбираться на примере Assembly-load-remap. Тест направлен на перенаправление на нужную версию библиотеки. Так как используется для парсинга имени библиотеки mono_assembly_name_parse и заполняется структура в build_assembly_name (по-сути дублирующая вышеописанную логику). Так как там применяется та же логика, что и раньше, то при применении новой логики (заполнение culture сразу, без флага в значении "", обращении к has_version при нахождении его) возникают ошибки далее по выполнению. Пока не нашел корень проблем. Возникла идея использовать mono_assembly_name_parse в новой логике (хотя бы попробовать), оставив правильно настроенный вывод. Возможно, это хороший вариант
Проблема с прохождением теста по ошибке, выводимой средой выполнения, связана с неккоректной культурой библиотеки.Ошибка возникает в конструкторе System.Globalization.CultureInfo. Unhandled Exception: System.Globalization.CultureNotFoundException: Culture name neutral is not supported. Parameter name: name at System.Globalization.CultureInfo..ctor (System.String name, System.Boolean useUserOverride, System.Boolean read_only) [0x00073] in <4d80528c8893419189250cc586595c12>:0 at System.Globalization.CultureInfo.CreateCulture (System.String name, System.Boolean reference) [0x00023] in <4d80528c8893419189250cc586595c12>:0 Я пытался наладить отладку управляемого кода при помощи https://github.com/mono/sdb (уже использовался ранее). Однако, при настройке переменных программы так, чтобы она использовала собранный Mono, а не с /usr, при данной настройке переменных, которая по мне верна, старт программы не происходит... *** 'RuntimeExecutable' = '/home/alexger97/Projects/mono/inst/bin' 'RuntimePrefix' = '/home/alexger97/Projects/mono/inst' *** Пока не понял, как мне найти корень проблемы, так как отладка кода Си пока не дала результата.
Ссылки на программу, которая показывает различие между поведением mono и framework, здесь нет. Конечно, лучше всего, чтобы тест был в виде теста: то есть показывал несовпадения с эталоном. Но если такого нет, то нужно проанализировать результаты и записать по каждому из них, какая есть проблема с примером и как её планируется исправить (как исправлена). Если проблема не зафиксирована, не ясно, что исправлять, и как проверять результат, и где искать ошибку в исправлении.
1. Доработал тест на основе вчерашних замечаний https://github.com/alexger97/AssemblyResolveTest 2. Изменил логику в assembly_name_to_aname для того, чтобы новый тест проходил 3. Сделал серию комитов: по каждой теме. Ее можно увидеть в https://github.com/alexger97/mono/commits/new_modern Так как внутренние тесты все равно отказываются проходится (5 штук), то стал искать в чем может быть проблема.Так, например, нашел очевидную проблему : при задании структуры, вне уже исследованных функций (при remap, например), естественно, никто не задает флаги присутствия культуры и версии, это я обнаружил отлаживая ловя в mono_stringify_assembly_name. Так добавились еще два комита в две функции, однако даже для того теста, что я отлаживал в конечном итоге это не решило проблему... Я не совсем понимаю, почему тест app-both.exe, не проходит при запуске с релизной версии моно (в контексте своей папки, как и положено) и при доработанной с помощью новых комитов mono. Рушится с одной и той же ошибкой... Понял, для себя момент, что изменяемая MonoAssemblyName присутствует во многих других структурах, чаще всего в MonoAssembly, но не могу понять, почему при добавлении двух сигнальных полей и по сути небольшого изменения логики в двух функциях, в которых программа не ловится, абстрактный ломающийся тест не использует их и при этом все равно происходит нарушение логики выполнения
1. Убрал помарки из коммитов. 2. Заменил ветку в fork-репозитории. 3. Мои пулреквесты закрыли для слияния. (все ссылки есть выше) 4. Вынес коммиты в патчи для быстрого применения. 4. Странное поведение с тестами. В репозитории ~/Projects/mono2 собрал с нуля последнюю версии mono (из мастера). Там при данной сборке при выполнении тестов валится pinvoke11.exe, который ломался и в ~/Projects/mono, собранной с рабочего тега, и thread-exit.exe. При применении моих патчей к неработающим тестам добавились три : bug-30085.exe, assemblyresolve_event4.exe, assemblyresolve_event3.exe. При отладки заметил уже знакомую вещь при обработке имени библиотеки - не отмечены флаги. В стеке удалось найти первое упоминание ves_icall_System_Reflection_AssemblyName_GetNativeName как функции из которой пришла данная библиотека. Хочу добить данные тесты, чтобы получить оптимальное решение
Сделал изменения, которые можно увидеть в пул-реквесте : https://github.com/mono/mono/pull/19876 Удалось добиться того, что тесты проходят (кроме одного, который валится всегда). Основная проблема была в том, чтобы отследить где еще заполняется структура MonoAssemblyName и добавить новый флаг на присутствие заданного ключа сборки (вариант - ключ передан как null ранее был упущен)
По предложенным мною изменениям - реакция положительная. Проблема в том, что при отдельном тестировании библиотеки Corlib - выявляются ошибки при прогоне тестов. Проблема, конечно, обидная так как, считал, что основные проблемы позади. Так, чтобы воспроизвести проблему нужно : mcs/class/corlib make run-test Видно, что, около 15 тестов не проходят. Так как было затруднительно запускать тесты через nunit-console.exe (почему-то, при запуске писал, о ошибке доступа). Сделал тест в виде программы, который повторяет первый непроходящий тест https://gitlab.eterfund.ru/alexger97/MonoBuildTest Так, при его отладке, видно, что проблема таже: не приходит в mono_stringify_assembly_name при заданных культуре, версии, ключе правильно заданные флаги о их присутствии. Пока не нашел того места, где именно происходит проблемная инициализация : скорее всего механизм "remap", где присваивается для библиотеки последняя рабочая версия среды выполнения. Так нашел функцию mono_try_assembly_resolve_handle (https://github.com/mono/mono/blob/eaa32d13659f0a6b6b5e62ddb49af68b1f9efb6c/mono/metadata/appdomain.c) из который вызывается именно тот, метод в который передается в конечном итоге параметры библиотеки
Решил попробовать выделить новую функцию конкретно под случай, который вызывается в mono_domain_assembly_postload_search там решил использовать новую функцию mono_stringify_assembly_information_out, которая является копией доработанной mono_stringify_assembly_name. Также исправил момент в mono_assembly_get_assemblyref по инициализации флага на присутствие ключа... Информация : https://github.com/mono/mono/pull/19876/files Однако, это все равно не то, что "доктор прописал", но уже лучше :4 успешные проверки в azure. Меня немножко осенило, с подачи умных людей, попробовать использовать противоположную логику в флагах : не задан параметр, а не был задан. Тогда, учитывая то, что множество тех функций, в которых происходит заполнение структуры для нашего момента строго известно (я уверен в этом), а во всех других случаях нам не важны данные поля, то такая логика даст, как мне кажется, построить работающую модель. Также сделал автоматизированный тест, на основе AssemblyResolveTest https://github.com/alexger97/AssemblyResolveTest/blob/master/AssemblyResolveTest/Program.cs Использование вывода ошибки в их тестах, без использования специальных фрамеворков тестирования - нормальная практика, так что осталось прописать для make путь файла с кодом
Проблема с тестами от Net Core, которые используются в Mono. Это : System.Resources.ResourceManager.Test :https://github.com/dotnet/runtime/blob/master/src/libraries/System.Resources.ResourceManager/tests/ResourceManagerTests.cs - один тест System.Private.CoreLib/System.Reflection.RuntimeMethodInfo https://github.com/dotnet/runtime/blob/0a2f0e6da98a784601b37d19417b930a33b2c478/src/coreclr/src/System.Private.CoreLib/src/System/Reflection/RuntimeMethodInfo.cs#L339 Информация : https://dev.azure.com/dnceng/public/_build/results?buildId=678206&view=logs&j=92132191-564b-5f39-0a04-729aa5393fc9&t=4be926ad-7ef2-585b-5f89-13e8577bd2ab Пока не удалось повторить тесты из-за того или получить то имя, передаваемое в Type.GetType (*) при котором происходит неправильное поведение из-за неявности оного без просмотра в ходе выполнения
Наконец-то, удалось решить проблему с непрохождением тестов от corefx. Изменил: логику флагов и нашел место, где не было предусмотрено "обнуления" данных только что созданной структуры MonoAssemblyName. Добавления memset(*) помогло. Также у меня уже есть тест, которые показывает проблему. Добавил его в mono/test, заставив его даже проходится, указанием его в make файлов. Однако, логика до конца мне не понятна, буду разбираться Видимые изменения : https://github.com/mono/mono/pull/19876/files Однако, какая-та ошибка с запуском других тестов, не срабатывает какой-то тригер, пока не понял почему...
Большое разочарование, что вчерашнее "прохождение" тестов, как мне кажется, является какой-то ошибкой. Добавил тест assemblyresolve_event7.cs, а так же при отладке https://gitlab.eterfund.ru/alexger97/MonoBuildTest/tree/master/MonoBuilTest3, который повторял один из тестов, который не проходил, добавил еще один memset(*) в функцию mono_class_from_typeref_checked в class.c. Сегодня : https://github.com/mono/mono/pull/19876/checks?sha=4d9de1a43f6694eb0a50a049ee478632dee09809 Вчера : https://github.com/mono/mono/pull/19876/checks?check_run_id=776242572 Сегодня и вчера 8 тестов не проходят. Стал делать программу по WCF, так чтобы попробовать использовать System.Private.ServiceModel для Net Standart
Проблема с тестами лежит в том, что в Azure они запускают Dotnet Core 5 с замененными частями Mono, при этом нет пока точного понимания как это повторить,а жаль. Существует возможность добавить в те участки кода, где не используется "обнуление" памяти под структуру MonoAssemblyName, эту часть функционала можно добавить и, скорее всего, это решит окончательно проблему, однако, это не лучший путь с точки зрения точечности решения проблемы
(Ответ Алексей Герасимов на комментарий #24) > Проблема с тестами лежит в том, что в Azure они запускают Dotnet Core 5 с > замененными частями Mono, при этом нет пока точного понимания как это > повторить,а жаль. > Вот что они делают: 1. собирают mono 2. скачивают .NET Core 5 runtime и тесты к CoreFX. 3. заменяют части .NET Core библиотеками из mono: cp ../mono/mini/.libs/libmonosgen-2.0.so shared/Microsoft.NETCore.App/5.0.0-alpha.1.19564.1/libcoreclr.so cp System.Private.CoreLib/bin/x64/System.Private.CoreLib.dll shared/Microsoft.NETCore.App/5.0.0-alpha.1.19564.1 cp System.Private.CoreLib/bin/x64/System.Private.CoreLib.pdb shared/Microsoft.NETCore.App/5.0.0-alpha.1.19564.1 4. Запускают тесты corefx с помощью этого модифицированного .NET Core
Сегодня удалось разобраться, что и как заменяют в проекте с Core и используют для проведения тестов. То, что писал Виталий выше удалось повторить, опираясь также на вывод тестирования на Azure. В папке Projects у меня есть папка .NetCore5, где путем подмены нужных файлов получаем ту солянку, которую они используют. Выделив из вывода тестирования 9 библиотек с непроходящими тестами, скачав их, видно, что каждый из них при запуске с ./RunTest.sh не выполняется. Большая проблема есть с тем, как используя gdb подключатся к выполнению кода ядра и анализировать его, так корректный запуск - используя скрипт, например, вот Projects/mono2/c_test/System.Configuratiuon.ConfigurationManager/RunTests.sh Два варианта : подключение к процессу (слишком мало времени) и запуск через gdb bash и далее скрипта - тут проблема в том, что все действо происходит в дочернем процессе, куда попасть непросто Через dotnet напрямую пока не получается запустить тесты так, чтобы поймать ошибку, хотя уже при моих мытарствах удалось как-то попасть в нужное место и поймать "ошибку" в виде неправильного инициализирования MonoAssemblyName в mono_assembly_name_from_token, скоро исправлю.
(Ответ Алексей Герасимов на комментарий #26) > Сегодня удалось разобраться, что и как заменяют в проекте с Core и > используют для проведения тестов. То, что писал Виталий выше удалось > повторить, опираясь также на вывод тестирования на Azure. Ты не должен ссылаться. Ты напиши, как ты повторил, чтобы это можно было повторить. > В папке Projects у меня есть папка .NetCore5, где путем подмены нужных > файлов получаем ту солянку, которую они используют. Возможно, стоит создать скрипт для подмены. ... > Два варианта : подключение к процессу (слишком мало времени) и запуск через Ну можно сделать больше времени — поставить паузу в начале теста.
Повторил, так : C помощью скрипта https://docs.microsoft.com/ru-ru/dotnet/core/tools/dotnet-install-script (указав место установки --install-dir * и --version 5.0.100-preview.5.20279.10) установлена .Net Core SDK соответствующей версии. Далее в каталоге были заменены из каталога с Mono : /mono/mini/.libs/libmonosgen-2.0.so (также скопировал libmonosgen-2.0.so.1.0.0 ссылкой на которую является первая библиотека) на shared/Microsoft.NETCore.App/5.0.0-alpha.1.19564.1/libcoreclr.so; Также /mono/netcore/System.Private.CoreLib/bin/x64/System.Private.CoreLib.dll был скопирован на замену одноименной библиотеки в shared/Microsoft.NETCore.App/5.0.0-alpha.1.19564.1. Далее, изменил в папках с тестами в *.runtimeconfig.json версии среды исполнения с 5.0.0 на 5.0.100-preview.5.20279.10. Далее запускаем скрипт RunTest.sh -r путь до папки со средой выполнения.
К сожалению, не получается повторить то, что удавалось вчера... При вышеописанных манипуляциях тестовые программы, которые не проходили ранее, пишут : ошибка фрагментации или exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped. Очень странно, ведь количество действий небольшое и нет сложных манипуляций. Грешил на неправильную сборку, но убедился, что дело не в ней. Однако, простые программы типа "хеллоу ворлд" работают... Создал версию под .Net Core ранее используемого теста https://gitlab.eterfund.ru/alexger97/MonoBuildTest его запустить не удается. Работаю над тем, чтобы добавив "обнуление" во всех приемлемых местах, собрать (сейчас с таким подходом - ошибка тестов), а далее имея список тестов все-таки прокрутить их и если все хорошо - пойти от обратного для того, чтобы не сильно перегружать код
https://github.com/mono/mono/pull/19876 -- Пулл реквест ожидает выполнения тестов. https://github.com/dotnet/runtime/pull/37156 -- Пулл реквест готов к слиянию в master
Странное дело - при коммите небольшого изменения теста assemblyresolve7, который ранее был закоммичен с ошибкой, тесты в dotnet runtime перестали проходиться. Далее, после того, как изменил функцию assembly_name_to_aname (переставил memset(*) под создаваемую MonoAssemblyName до инициализации ее полей) тесты опять стали проходить. Вообщем, загадка Нашел способ как запускать скрипт на работу Core с подменяемым ядром Mono. /mono/netcore ./build.sh --test Очень странно, при выполнении всех манипуляций выдает "Ошибка сегментирования", тут явно дело в окружении запуска, как по мне. Все запускалось/собиралось на builder64
В Projects/mono2/mono/netcore сделал git pull. Запустил build.sh --rebuild . После этого произошла пересборка всего содержимого. Это помогло. Далее при build.sh --test стало происходит выполнение тестов. Из того, что есть на данный момент : Проблемы возникают с corefx/tests/extracted/Microsoft.VisualBasic.Core.Tests Очень странно, так как везде ошибка: Microsoft.VisualBasic.Tests.ConversionsTests.ToString_IConvertible_ReturnsExpected(value: не число, expected: "NaN") [FAIL] Assert.Equal() Failure Expected: NaN Actual: не число corefx/tests/extracted/System.Globalization.Extensions.Tests Здесь две ошибки Очень было бы полезно использовать возможность gdb с подключением к процессу, однако есть проблемы : https://bugs.etersoft.ru/show_bug.cgi?id=14570 Но все же удалось запустить с помощью gdb. Так находясь в каталоге с тестами : gdb /home/alexger97/Projects/mono2/mono/netcore/dotnet Далее (под конкретный тест, команда есть в RunTest.sh) : set ars exec --runtimeconfig System.Reflection.TypeExtensions.CoreCLR.Tests.runtimeconfig.json xunit.console.dll System.Reflection.TypeExtensions.CoreCLR.Tests.dll -xml testResults.xml -nologo Далее - run и все готово
Большая просьба — всегда использовать копирование при заполнении багзиллы, не надо переписывать свои команды или вывод команд руками. Во-первых, обычно видно, сколько при этом вносится опечаток. Во-вторых, ценность записи теряется — нет подлинности, есть неизвестные опечатки. Но не важно, почему это плохо, потому что это просто неприемлемо.
Прошу прощения, допустил ошибку при внесении данных в прошлый раз, как минимум пропустил g в set arGs ... По поводу пул-реквестов: https://github.com/mono/mono/pull/19876 - здесь при запуске тестов не проходят последние три проверки: Первая : https://jenkins.mono-project.com/blue/organizations/jenkins/test-mono-pull-request-coop/detail/test-mono-pull-request-coop/25318/pipeline Здесь видно, что проблема с MonoTests.Microsoft.Build.Utilities.TaskLoggingHelperTest.TestFormatResourceString3 и MonoTests.Microsoft.Build.Utilities.TaskLoggingHelperTest.TestLogMessageFromResourcesNonExistantResourceName Вторая : https://jenkins.mono-project.com/blue/organizations/jenkins/test-mono-pull-request-arm64-fullaot%2Bllvm/detail/test-mono-pull-request-arm64-fullaot%20llvm/17875/pipeline Здесь пока не смог найти конкретных данных по ошибкам, кроме таких данных, как : Error Parsing /*.dll: Format of the executable (.exe) or library (.dll) is invalid. Третья : https://jenkins.mono-project.com/blue/organizations/jenkins/test-mono-pull-request-wasm/detail/test-mono-pull-request-wasm/23095/pipeline Пока не понял, в чем суть, так как пытался повторить первый тест Для этого добавил : https://gitlab.eterfund.ru/alexger97/MonoBuildTest/tree/master/MicrosoftBuildUtilities Пытался зацепится gdb и найти проблему: пока не нашел.
Довольно непонятно, почему происходит падение. Тщательно разбирал логи падения в В трех тестах проблема обозначена при сборке соответственно corlib - Unstable, runtime - Unstable и debugger Unstable. При том в случае с Linux AArch64 FullAOT+LLVM runtime Unstable, а corlib Passed. Хотя имеет один Inconclusive тест. В случае с Linux x64 Coop Suspend ситуация противоположная. Еще перевариваю весь массив информации, запускал несколько тестов, подключившись по gdb. Несколько зацепок : С FullAOT+LLVM есть ошибка, пока не знаю как повторить Executing the native assembler: "as" -o /tmp/mono_aot_Gn9kpe.o /tmp/mono_aot_Gn9kpe Executing the native linker: "ld" -shared -o /home/builder/jenkins/workspace/test-mono-pull-request-arm64-fullaot+llvm/mono/tests/assembly-load-reference/separatedir/middle/Dep.dll.so.tmp "mono_aot_p9u3ic/temp-llvm.o" /tmp/mono_aot_Gn9kpe.o JIT time: 0 ms, Generation time: 84 ms, Assembly+Link time: 33 ms. MONO_PATH=/home/builder/jenkins/workspace/test-mono-pull-request-arm64-fullaot+llvm/mcs/class/lib/testing_aot_full ../../../runtime/mono-wrapper --runtime=mobile -O=gsharedvt --llvm --aot=full,nimt-trampolines=2000,ntrampolines=10000,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4400,nftnptr-arg-trampolines=4000,nrgctx-trampolines=21000 mainanddep/middle/Mid.dll Unable to compile method 'void MyType:Method ()' due to: 'Could not load file or assembly 'Dep, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.'. Mono Ahead of Time compiler - compiling assembly /home/builder/jenkins/workspace/test-mono-pull-request-arm64-fullaot+llvm/mono/tests/assembly-load-reference/mainanddep/middle/Mid.dll AOTID 027E4A75-7E1C-24CF-599F-9678133D70F9 Executing opt: "opt" -f -O2 -disable-tail-calls -place-safepoints -spp-all-backedges -o "mono_aot_VUsZew/temp.opt.bc" "mono_aot_VUsZew/temp.bc" Executing llc: "llc" -enable-implicit-null-checks -disable-fault-maps -march=aarch64 -asm-verbose=false -disable-gnu-eh-frame -enable-mono-eh-frame -mono-eh-frame-symbol=mono_aot_Mid_eh_frame -disable-tail-calls -relocation-model=pic -filetype=obj -o "mono_aot_VUsZew/temp-llvm.o" "mono_aot_VUsZew/temp.opt.bc" и ссылка на непроходящий тест, который пока не понял откуда его взяли https://jenkins.mono-project.com/job/test-mono-pull-request-arm64-fullaot+llvm/17875/testReport/MonoTests/test-sgen-regular-ms-conc-simple/sgen_new_threads_dont_join_stw_exe/
Из лога https://jenkins.mono-project.com/job/test-mono-pull-request-coop/25318/consoleFull все-таки видно, что последнее, что делает программа, это запускает MonoTests.System.ExceptionTest.DumpICallTotalRepeated Если сравнить с другим тестом https://jenkins.mono-project.com/job/test-mono-pull-request-arm64/30682/consoleFull видно, что после прохождения данного теста, есть еще целая цепочка тестов. https://github.com/mono/mono/blob/4b83678a4ad02baf528b6413f49c5d10e1c7a12d/mcs/class/corlib/Test/System/ExceptionTest.cs -- файл с описанием теста Из того, что было упущено мной : вызов g_strchomp ((char*)assembly->name), где assembly->name const char *, что потенциально, есть очень неправильно. Далее, еще из возможных причин, есть то, что отсутствует наполнение структур, отвечающих за MonoAssemblyName на c#, про то, что писали в https://github.com/mono/mono/pull/19876#issuecomment-636877105 Я добавил в необходимые структуры данные три поля типа bool (without_*), компиляция прошла успешно, однако на этапе тестов получил кучу ошибок. Очень бы не хотелось погружаться и в эту проблему (правильное отображение полей и их заполнение вместе с другими, так как может начаться процесс расползания проблем уже из-за изменения данных структур)
Патч был разбит на две части: первая относится к правильной обработки поступающей строки в assembly_name_to_aname. В случае с различными сочетаниями пробелов в различных местах. Вторая часть подразумевает остальную логику : по внедрению флагов на присутствие флагов на обнаружение в строке версии и культуры, токена и дальнейшую работу по доведению до ума. По первой части сделал пулл-реквест : https://github.com/mono/mono/pull/20152 очень надеюсь, что не возникнет сомнений, что данный код есть грамотным и корректным. В копии для dotnet идиотское падение одного теста, которое, уверен, никак не относится к мои изменениям. https://github.com/dotnet/runtime/pull/39837 Также создал issue по поводу обнаруженной проблемы с вызовом исключения в обработчике события на неудачную загрузку https://github.com/mono/mono/issues/20153
Проект заморожен. Ставлю: LATER
Бага закрыта
