| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
* Backport https://github.com/dotnet/runtime/pull/76665
|
|
|
|
As a part of https://github.com/dotnet/arcade/issues/10123, we are moving all docker containers to the new tagging schema
|
|
Grep now prints warning messages when using `egrep` and `fgrep`
Replacing with the standard `grep -E` and `grep -F`
This change is released under the MIT license.
Signed-off-by: Nicolas signed-log FORMICHELLA <stigpro@outlook.fr>
|
|
The old ones are getting deprecated.
|
|
|
|
In this particular case, one of the method arguments has a type that
can not be resolved and the signature code returns null.
|
|
This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.
|
|
Update memory usage calculation in line with comments made in [coreCLR cgroup PR](https://github.com/dotnet/runtime/pull/64128).
The other significant change is the use of `sysconf(_SC_PHYS_PAGES)`. In the earlier version of this code I had used `sysconf(_SC_AVPHYS_PAGES)`. The latter is often significantly smaller (by an order of magnitude) to the former meaning that the value returned may be quite low. However, I am unsure whether mono already takes this into account. For example, running in with no-cgroup restrictions on a 16G virtual machine would report a `_SC_AVPHYS_PAGES` value of 79138 pages resulting in a memory value of 324149248 bytes (309MB) being returned. When setting cgroup constraints:
```
systemd-run -q --scope -p CPUQuota=400% -p MemoryLimit=13G
```
We'd also return 309MB. Using `_SC_PHYS_PAGES` where a value of 4118237 pages is returned then the memory value returned is substantially higher.
|
|
|
|
Fixes https://github.com/dotnet/runtime/issues/72181
|
|
|
|
Backport https://github.com/dotnet/runtime/pull/71436
|
|
(cherry picked from commit 6051b710727762fd96367a7c32400d68533e63cb)
|
|
When a domain is unloaded, it is possible that an InternalThread
has a reference to an app context from the unloaded domain.
|
|
(#21481)
Fixes dotnet#67354.
|
|
Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
|
|
methods. (#21470)
This is a backport of https://github.com/dotnet/runtime/pull/59182.
|
|
* Use upstream zlib 1.2.12
* [zlib] Cherrypick upstream crc32 fix
Cherrypick crc32 fix to restore pre-1.2.12 behavior
https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2
> The previous releases of zlib were not sensitive to incorrect CRC
> inputs with bits set above the low 32. This commit restores that
> behavior, so that applications with such bugs will continue to
> operate as before.
|
|
section. (#21451)
* [AOT] Don't set the 'CorrectedSynthesize' flag in the objc_imageinfo section.
According to Apple's headers, it's not used anymore, and ignored.
However, with Xcode 13.3, it seems Apple has re-used this value for something
else, and it's causing warnings in the linker:
> ld: warning: '[...]/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
Fixes https://github.com/mono/mono/issues/21450.
Ref: https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-abi.h.auto.html
* Don't set the 'CorrectedSynthesize' flag when using LLVM either.
|
|
|
|
|
|
Introduced by f9d44382fbb9331865283d8500f181ae18d99e3b
|
|
as return types from pinvoke callbacks. (#21402)
Fixes https://github.com/dotnet/runtime/issues/63962.
|
|
* Create connfig.yml
* Update and rename .github/ISSUE_TEMPLATE.md to .github/ISSUE_TEMPLATES/mono-framework.md
|
|
Fixes https://github.com/xamarin/xamarin-android/issues/6600
Backported from https://github.com/dotnet/runtime/pull/64679 and https://github.com/dotnet/runtime/pull/65373
|
|
|
|
One of the changes in macios revealed a bug in which @new can be null
resulting in a NRE like the one that follows:
System.NullReferenceException: Object reference not set to an instance of an object
2022-01-26T09:23:11.9538790Z at Mono.ApiTools.MarkdownFormatter.DiffModification (System.Text.StringBuilder output, System.String old, System.String new, System.Boolean breaking) [0x00013] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/MarkdownFormatter.cs:181
2022-01-26T09:23:11.9543530Z at Mono.ApiTools.ApiChange.AppendModified (System.String old, System.String new, System.Boolean breaking) [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiChange.cs:49
2022-01-26T09:23:11.9547700Z at Mono.ApiTools.FieldComparer.Equals (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges changes) [0x0008c] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/FieldComparer.cs:123
2022-01-26T09:23:11.9551430Z at Mono.ApiTools.MemberComparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00053] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/MemberComparer.cs:111
2022-01-26T09:23:11.9554840Z at Mono.ApiTools.MemberComparer.Compare (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target) [0x00064] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/MemberComparer.cs:66
2022-01-26T09:23:11.9558230Z at Mono.ApiTools.ClassComparer.Modified (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges diff) [0x00172] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ClassComparer.cs:238
2022-01-26T09:23:11.9562840Z at Mono.ApiTools.Comparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00084] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/Comparer.cs:94
2022-01-26T09:23:11.9566810Z at Mono.ApiTools.ClassComparer.Compare (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target) [0x0002c] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ClassComparer.cs:68
2022-01-26T09:23:11.9570610Z at Mono.ApiTools.NamespaceComparer.Modified (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges differences) [0x00017] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/NamespaceComparer.cs:79
2022-01-26T09:23:11.9574480Z at Mono.ApiTools.Comparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00084] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/Comparer.cs:94
2022-01-26T09:23:11.9578000Z at Mono.ApiTools.NamespaceComparer.Compare (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target) [0x0002c] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/NamespaceComparer.cs:51
2022-01-26T09:23:11.9581650Z at Mono.ApiTools.AssemblyComparer.Modified (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges diff) [0x00055] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/AssemblyComparer.cs:89
2022-01-26T09:23:11.9586220Z at Mono.ApiTools.Comparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00084] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/Comparer.cs:94
2022-01-26T09:23:11.9589520Z at Mono.ApiTools.AssemblyComparer.Compare () [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/AssemblyComparer.cs:63
2022-01-26T09:23:11.9592880Z at Mono.ApiTools.ApiDiffFormatted.Generate (Mono.ApiTools.AssemblyComparer ac, System.IO.TextWriter outStream, Mono.ApiTools.State state) [0x00013] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:222
2022-01-26T09:23:11.9596490Z at Mono.ApiTools.ApiDiffFormatted.Generate (System.String firstInfo, System.String secondInfo, System.IO.TextWriter outStream, Mono.ApiTools.State state) [0x00008] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:208
2022-01-26T09:23:11.9600250Z at Mono.ApiTools.ApiDiffFormatted.Generate (System.String firstInfo, System.String secondInfo, System.IO.TextWriter outStream, Mono.ApiTools.ApiDiffFormattedConfig config) [0x00007] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:202
2022-01-26T09:23:11.9603590Z at Mono.ApiTools.Program.Main (System.String[] args) [0x002f9] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:159
The change that exposed the bug is: https://github.com/xamarin/xamarin-macios/commit/d78aa6712b15659b0fed259952364c060ffedcea
The above exception is avoided by ensuring that nor old or @new are
null.
|
|
method (#21356)
* [mono] Fix StackTrace from a dim and Vtable offsets for static interface method
- Fix StackTrace when called from a DIM.
- Fix the other test case that was added for @bholmes, and this case when the method `TestMethod5` was being called it was executing `TestMethod10`, and this was fixed skipping static interface methods when was calculating vtable offsets.
The fix was completely done by @vargaz, I just opened the PR.
Thanks @vargaz .
Fix https://github.com/dotnet/runtime/issues/60486
* mono_get_generic_info_from_stack_frame fix for default interface methods
The context is a MonoMethodRuntimeGenericContext when the method is a
default interface method.
Related to https://github.com/dotnet/runtime/issues/62334
Co-authored-by: thaystg <thaystg@users.noreply.github.com>
Co-authored-by: Bill Holmes <bill.holmes@unity3d.com>
|
|
When processing the overrides from interface default methods we should
check if the interface class is a generic type definition first and
inflate with the interface class context.
Fixes dotnet/runtime#61244
Co-authored-by: bholmes <bholmes@users.noreply.github.com>
|
|
When the field is byref but the value being passes in is not, throw an
ArgumentException. Without this change the call to
mono_object_handle_pin_unbox will assert and kill the process.
This can occur when de-serializing an object and the field types have
changed.
Co-authored-by: bholmes <bholmes@users.noreply.github.com>
|
|
Xamarin.Android is trying to (partially) switch to LLVM-based toolchain
and it appears that the llvm-mc assembler doesn't accept .hword as a
valid directive for x86 targets. Since it's an alias for .short,
which works fine, the change should be safe across all the architectures
supported by AOT.
|
|
Add capability to interrogate cgroup limitations when determining CP and memory limits
This code has been adapted from coreCLR. It has been modified from C++ but uses the same naming conventions in the event of a unified mechanism that can be shared between both runtimes being developed. The code has been tested on Ubuntu 20.04 and CentOS 7 with cgroupv1 and cgroupv2.
This code is required in the event of running mono in a container as the current limitations being discovered by mono are purely for the machine and not in a container which may have lower quotas.
* mono/utils/Makefile.am
- Add new file to build
* mono/utils/memfuncs.c
- Call `getRestrictedPhysicalMemoryLimit()` or `getPhyscalMemoryAvail()`
* mono/utils/memfuncs.h
- Add prototypes for the new APIs
* mono/utils/mono-cgroup.c
- Code adapted from coreCLR to interrogate sysfs to determine any limitations on memory or CPU
* mono/utils/mono-proclib.c
- Add call to `getCpuLimit()`
* mono/utils/mono-proclib.h
- Add prototype for the new API
|
|
The mono_field_static_get_value method uses a handle, but did not set up
enter/exit macros properly, so this handle was leaked.
Some code in Unity calls this embedding API method pretty often, which
can lead to the mark stack overflowing in the GC code.
|
|
It does require internet access.
|
|
These structures are valuetypes, but their mint_type is a primitive. This means that a LDFLD applied on the type would have attempted to do a pointer dereference, because it saw that the current top of stack is not STACK_TYPE_VT. This was fixed in the past by passing the managed pointer to the valuetype rather than the valuetype itself, against the normal call convention, which lead to inconsistencies in the code.
This commit removes that hack and fixes the problem by ignoring LDFLD applied to nint/nfloat valuetypes in the first place.
|
|
job_major_mod_union_preclean (#21384)
fixes #21369
Related to https://github.com/xamarin/xamarin-android/issues/6546
job_major_mod_union_preclean can race with the tarjan bridge
implementation that changes the vtable pointer by settings the three
lower bits. this results in invalid loading of the vtable
(shifted by 7 bytes) which in turn give a wrong desc to the scan
functions
This change is released under the MIT license.
|
|
Fixes https://github.com/mono/mono/issues/21372 by changing index in dump_blob from int to guint32
This change is released under the MIT license.
|
|
* [tests] Add CCW GetIUnknownForObject leak test
* [cominterop] Add coop handle enter/return on native CCW methods
The CCW methods for IUnknown (and in principle IDispatch - except they all have
trivial bodies) are native C code in the runtime that may allocate coop
handles. Add a coop handle frame around the entire call in order to make sure
they're cleaned up and don't retain a reference.
This helps fix managed object leaks with code like:
```
var o = new SomeClass();
var pUnk = Marshal.GetIUnknownForObject(o);
int c = Marshal.Release(pUnk);
o = null;
```
Which retains a reference to the `SomeClass` instance that won't be collected
until the thread dies, despite cleaning up the IUnknown refcount. The underling
ccw addref/release methods leak coop handles on the thread.
This is not an issue when the CCW calls some managed method because there are
no coop handles there until some icall (at which point it will set up the
coop handle stack properly).
|
|
The previous implementation created a temporary array and threw the
result away before copying back to the Span.
This commit brings a similar implementation to what is in dotnet/runtime
repo.
|
|
|
|
monterey (#21326)
New MacOS Monterey is not correctly resolving dylib locations when dllmap configuration is not specifying full paths, this makes VS4Mac use libcairo-2.dll from a dependency of a installed library in Hombrew.
A workaround was set full path to libcairo-2 and this fixed the problem.
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
Implement method name wildcard matching for method descriptions
Globbing doesn't work because we don't have g_pattern_match_simple in eglib.
But a plain '*' wildcard does work.
Also `'className:*'` works. (`*:methodName` already worked)
Co-authored-by: lambdageek <lambdageek@users.noreply.github.com>
|
|
They are no longer needed here.
|
|
We don't use these feeds in mono/mono.
|
