Add a commit message with a pointer to the maccore hash that GitHub renders as
a link when publishing an mlaunch binary to the macios-binaries repository.
This will hopefully make it _slightly_ easier to review since verifying the
maccore hash is now just a click away.
This fixes this:
Unexpected exception: System.AggregateException: One or more errors occurred. (One or more errors occurred. (ApplicationName='[...]/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mlaunch', CommandLine='--listsim=/var/folders/43/h027tm1n101cdrq2_b6n9n2m0000gn/T/tmp12c3d415.tmp --output-format=XML', CurrentDirectory='', Native error= Cannot find the specified file)) ---> System.AggregateException: One or more errors occurred. (ApplicationName='[...]/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mlaunch', CommandLine='--listsim=/var/folders/43/h027tm1n101cdrq2_b6n9n2m0000gn/T/tmp12c3d415.tmp --output-format=XML', CurrentDirectory='', Native error= Cannot find the specified file) ---> System.ComponentModel.Win32Exception: ApplicationName='[...]/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mlaunch', CommandLine='--listsim=/var/folders/43/h027tm1n101cdrq2_b6n9n2m0000gn/T/tmp12c3d415.tmp --output-format=XML', CurrentDirectory='', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
at System.Diagnostics.Process.Start () [0x0003a] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/System/services/monitoring/system/diagnosticts/Process.cs:2006
at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.Start()
at Microsoft.DotNet.XHarness.iOS.Shared.Execution.ProcessManager.RunAsyncInternal (System.Diagnostics.Process process, Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog log, Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog stdout, Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog stderr, System.Nullable`1[T] timeout, System.Collections.Generic.Dictionary`2[TKey,TValue] environmentVariables, System.Nullable`1[T] cancellationToken, System.Nullable`1[T] diagnostics) [0x00469] in [...]/xamarin-macios/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Execution/ProcessManager.cs:185
at Microsoft.DotNet.XHarness.iOS.Shared.Hardware.SimulatorLoader+<>c__DisplayClass16_0.<LoadDevices>b__0 () [0x00107] in [...]/xamarin-macios/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Hardware/SimulatorLoader.cs:65
at Microsoft.DotNet.XHarness.iOS.Shared.Hardware.SimulatorLoader.LoadDevices (Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog log, System.Boolean includeLocked, System.Boolean forceRefresh, System.Boolean listExtraData) [0x00155] in [...]/xamarin-macios/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Hardware/SimulatorLoader.cs:54
at Microsoft.DotNet.XHarness.iOS.Shared.Hardware.SimulatorLoader.FindOrCreateDevicesAsync (Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog log, System.String runtime, System.String devicetype, System.Boolean force) [0x0023c] in [...]/xamarin-macios/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Hardware/SimulatorLoader.cs:156
at Microsoft.DotNet.XHarness.iOS.Shared.Hardware.SimulatorLoader.FindSimulators (Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog log, System.Boolean create_if_needed, System.Boolean min_version) [0x00267] in [...]/xamarin-macios/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Hardware/SimulatorLoader.cs:277
at Xharness.Jenkins.TestTasks.RunSimulatorTask.FindSimulatorAsync () [0x0005a] in [...]/xamarin-macios/tests/xharness/Jenkins/TestTasks/RunSimulatorTask.cs:53
at Xharness.Jenkins.Jenkins.CreateRunSimulatorTasksAsync () [0x004ee] in [...]/xamarin-macios/tests/xharness/Jenkins/Jenkins.cs:558
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional (System.Boolean includeTaskCanceledExceptions) [0x00011] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2027
at System.Threading.Tasks.Task`1[TResult].GetResultCore (System.Boolean waitCompletionNotification) [0x0002b] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:496
at System.Threading.Tasks.Task`1[TResult].get_Result () [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:466
at Xharness.Jenkins.Jenkins+<>c__DisplayClass72_0.<PopulateTasksAsync>b__0 (System.Threading.Tasks.Task`1[TResult] v) [0x0001e] in [...]/xamarin-macios/tests/xharness/Jenkins/Jenkins.cs:941
at System.Threading.Tasks.ContinuationTaskFromResultTask`1[TAntecedentResult].InnerInvoke () [0x00024] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:155
at System.Threading.Tasks.Task.Execute () [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2319
--- End of stack trace from previous location where exception was thrown ---
* add error handling for storage path
* Revert "add error handling for storage path"
This reverts commit 751e54c254.
* revert whitespace changes, only add real change
* small fixes
This will ensure the file isn't kept open until the GC runs, and then
sometimes it can prevent other tasks or targets from opening it if the GC
hasn't run.
Fixes this problem:
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 1 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 2 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 3 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 4 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 5 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 6 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 7 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 8 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 9 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 10 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3027: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Exceeded retry count of 10. Failed.
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3021: Unable to copy file "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
Fixes https://github.com/xamarin/maccore/issues/2137.
Fixes https://github.com/xamarin/xamarin-macios/issues/8940.
Automatically detect which .NET version to use based on the global.json reachable from the project directory.
Due to how things are designed, some parts of the code wants the dotnet
executable before the code in question knows the project directory, which
isn't possible anymore. So there's a minor change to pass around a lambda that
can calculate the path to the executable instead of the executable itself.
Use both in those labs that support xamarin-storage so that we have a
backup. To do so, move the parameter to be a bool but keep the rest of
the logic the same.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [mono] bump momo to match android
New commits in mono/mono:
* mono/mono@109b4b6f44 [jit] Fix the Activator.CreateInstance () intrinsic for primitive types. (#19989) (#19994)
* mono/mono@15782aa740 If there is a crash and the debugger is attached, we call mini_get_dbg_callbacks ()->send_crash(). That call ends up in mono_debugger_agent_send_crash which does all kinds of questionable stuff like trying to take the loader lock. Eventually it ends up calling socket_transport_send which tries to do a transition to GC Safe mode. I inserted a MONO_ENTER_GC_UNSAFE in mono_debugger_agent_send_crash function and this fixes the assert. (#19992)
* mono/mono@6ea4cbcee0 [2020-02] [merp] Add API methods for getting hashcode/reason of last crash (#19978)
* mono/mono@d45ff3af75 [merp] Add tests for crashing via POSIX signal (#19977)
* mono/mono@bc1dd071a7 [merp] Add a test for Mono.Runtime.SendExceptionToTelemetry() (#19966)
* mono/mono@87ef555701 Emit DWARF debug_abbrev offset for compile units as a label instead of 0 (#19794)
Diff: 8c085a99b3..109b4b6f44
* Bump mono
* Revert "Emit DWARF debug_abbrev offset for compile units as a label instead of 0"
With this PR a very basic sample app will build and launch successfully in the simulator.
This PR is best reviewed commit-by-commit; each change is explained by its commit message.
This is particularly important when we have global.json and NuGet.config in
the project directory, because those are looked up starting with the current
directory, so those two need to match.
Try to create the folder in xamarin-storage, if that fails, rather than
stop with an error, execute the tests and st an env var.
Once the tests are complete, when adding the summaries, check if we did
fail to reach xamarin-storage and notify it.
This will make sure that tests won't fail if:
* xamarin-storage dies.
* bots are not in the vpn and could not reach xamarin-storage.
* Replace `memcpy` with `Buffer.MemoryCopy`
* Add cecil-based test to make sure we're not p/invoke into it again (nor any other MS banned API)
* Remove `memcpy` from xtro ignore file
`strlen` is part of the list of C API banned by Microsoft.
Also rename a local variable in `Runtime.cs` so grepping the source
files won't show `strlen` outside the `tests` subdirectories.
Vsdrops does not support serving a static html. Therefore we need to use
full uris that will be used to download the logs. To make things less
dangerous, we leave the xamarin-storage report as it was and create a
new one for vsdrops.
This means that:
1. xamarin-storage index.html is left as is.
2. vsdrops_index.html contains full uris to download (the env var will
have to be set in the step) and js and css are in the header.
3. because we use and env var, jenkins won't generate the
vsdrops_index.html only device pipelines will.
For this to take effect needs updates in the device pipelines. The
solution is not yet optimal since we need to add some workaround to
rather than make the monitoring person open a text file, we should
display it in the browser.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
This commit moves all the different pipelines we have to fully use yaml.
That includes the old ddfun pipeline that was using a mix between using
yaml and the UI interface to configure it.
The new pipelines are found under the tools/devops/device-tests
directory. All of the use a very similar structure and therefore we use
a template. The README.md inside the directory should explain most of
the logic and the devices-tests.yml contains comments for each of the
steps.
Most of the bash scripts have been moved to use pwsh which is inside the
scripts directory and contains tests. Tests can be ran via:
```bash
make -C tools/devops/device-tests/scripts run-tests
```
This commit will only affect the ddfun pipeline that will need to be
updated to use the new yml path. All the other pipelines are not
affected and they will be to be updated manually.
The pipelines support two different storages for the html report.
* xamarin-storage: Old school.
* vsdrops: New age.
Unfortunatly we yet do not know how to workaround the fact that vsdrops
does not serve the files, therefore we use the xamarin-storage in all
pipelines but those in the ddfun lab because they do not have the right
access.
This later can be easily changed editing the
tools/devops/device-tests/tempaltes/cambridge-variables.yml which will
update all the pipelines in the cambridge lab.
PS: Sorry for the size.
Refactor code to have a single method checks alignment, allocates (if
alignment is needed) and, optionally, copy the existing data
note: we already had tests for those manually bound API
Apple's charts say indirect command buffers are available with MTLGpuFamilyCommon2.
That's not quite so, devices that support MTLGpuFamilyCommon2 may crash when
MTLDevice.CreateIndirectCommandBuffer is called.
So make the conditions for calling CreateIndirectCommandBuffer an intersection
of the previous condition for macOS (MTLFeatureSet.macOS_GPUFamily2_v1) + the
new condition (MTLGpuFamily.Common2) + Xcode 11+ (just to make things
simpler).
I've tested this on all our macOS bots, and it worked on all of them.
If it fails anywhere else (iOS devices), the next patch will remove the entire
test.
Manuel de la Pena
Rolf Bjarne Kvinge
Whitney Schmidt
Alex Soto
Chris Hamons
Sebastien Pouliot