- 28 12月, 2020 6 次提交
-
-
由 Scott Ferguson 提交于
Corrects an issue where for the hour after the DST transition, the local UTC offset was listed. The UTC offset was the DST offset instead of the standard time offset. The runtime library captures this an ambiguous time. That is the local time that occurs twice - once in DST then once in standard time. If DST is an extra 1:00 a.m. offset and ends at 2:00 a.m., 1:00 a.m. to 1:59:59.9999.... occurs twice. First in DST then again in standard time. The classlibs had this incorrect - they did not consider 1:00 a.m. an ambiguous time, and considered 2:00 a.m. ambiguous. However it should be reversed. 1:00 a.m. occurs twice, but 2:00 a.m. only occurs once. The instance we would hit 2:00 a.m. DST, we instantaneous switch to 1:00 a.m. standard. The classlibs were also not recording enough information to record which side of DST a local time was. When converting a time from UTC, or using DateTime.Now an internal flag, IsAmbiguousDaylightSavingTime, should be set if the time is an ambiguous local time that is on the DST side of the transition. The classlibs were calling TimeZone.IsAmbigousTime which has a wider defintion for ambiguous time that the IsAmbiguousDaylightSavingTime should have. It returns true for local times on either side of DST. So a new method IsAmbiguousLocalDstFromUtc was added to check this case. The classlibs were also not checking the IsAmbiguousLocalDstFromUtc flag when getting the UTC offset for a local time. So a check was inserted in two locations to correct for that. Some tests has to be updated to reflect these new definitions of when DST starts and ends and which times are ambiguous. These also account for some test changes required by cherry-picked changes to TimeZoneInfo.cs where the corresponding test changes were not cherry-picked. Some of those changes where in PR's that updated to the CoreFx TimeZoneInfo class. All these changes have been verified against the behavior of the .Net Framework and they match. Fix case 1288231: Mono: Fix incorrect UTC offset during daylight savings time transitions
-
由 Maxim Lipnin 提交于
Addresses an issue with jumping into DST for some time zones when the incorrect date-time offset is returned for date-time in UTC (which comes from DateTime.Now). The fix is to just check if the incoming date-time is in UTC. Also added a set of tests for some time zones to verify jumping into DST in general. Fixes https://github.com/mono/mono/issues/16395
-
-
由 Maxim Lipnin 提交于
-
由 Maxim Lipnin 提交于
When a datetime appears in range of [end_of_DST_period - Daylight_delta; end_of_DST_period] it's not DST and should return base offset. Fixes #9664.
-
由 Maxim Lipnin 提交于
-
- 18 12月, 2020 2 次提交
-
-
由 ashwinimurt 提交于
-
由 ashwinimurt 提交于
-
- 11 12月, 2020 9 次提交
-
-
由 ashwini 提交于
-
由 lateralusX 提交于
There is a small race condition during the completion of a native thread join call. During that period of time the tid is no longer included on the internal list tracking joinable threads so a thread that will join on the tid while another thread (like the finalizer thread) is waiting on native join to complete for the same tid, will cause the managed Thread.Join call to complete before the native join call has completed. This race could cause issues on some OS:es that clear's up some thread resources, like abandoned mutexes when the thread has exited. This race is hit by WaitAnyWithSecondMutexAbandoned since the call to Thread.Join will return before the thread owning the mutex has terminated meaning that it doesn't get ownership of the abandoned mutex as assumed by the test. Fix makes sure Thread.Join won't complete until native thread join is complete. Increasing the join timeouts in the test also eliminates a timeout error making it harder to hit the problematic code path, primarily during reproduction in the debugger. Fix also switch to coop mutex for joinable threads.
-
由 Ryan Lucia 提交于
In managed, these functions are used as `static external IntPtr`. This means that previously on arm64 the top bits of the return value were garbage. A comparison with 64-bit -1 like in LinuxNetworkChange.EnsureSocket would never be true, which was causing us to hit other assertions in the runtime. Co-authored-by: NAleksey Kliger <alklig@microsoft.com>
-
由 Josh Peterson 提交于
Allow `CreateDelegate` to have return type covariance with methods that return `enum` or `int` types. This is from the upstream change at https://github.com/mono/mono/commit/122494330d635205b0a8766deaeafd0d79bd3d60.
-
由 Alex Thibodeau 提交于
After adding the concept of a pending threads join list boehm was not removing the threads from that list on detach as sgen was in sgen_client_thread_detach_with_lock. This change brings boehm in line with sgen to remove threads from the pending join list on detach to avoid waiting the full 2 seconds on runtime shutdown. (case 1295072)
-
由 Josh Peterson 提交于
These changes are applied from upstream Mono at https://github.com/mono/mono/pull/7308/commits/e25f5c321573b677ab9edcb88833ef40d267026c. They correct an exception that happens on Linux like this: ``` System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic number is wrong: 542 at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& position) [0x0008d] in /Users/bokken/build/output/Unity-Technologies/mono/mcs/class/corlib/System/TermInfoReader.cs:134 at System.TermInfoReader..ctor (System.String term, System.String filename) [0x0005f] in /Users/bokken/build/output/Unity-Technologies/mono/mcs/class/corlib/System/TermInfoReader.cs:97 at System.TermInfoDriver..ctor (System.String term) [0x00055] in /Users/bokken/build/output/Unity-Technologies/mono/mcs/class/corlib/System/TermInfoDriver.cs:164 at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x00000] in /Users/bokken/build/output/Unity-Technologies/mono/mcs/class/corlib/System/ConsoleDriver.cs:73 at System.ConsoleDriver..cctor () [0x0004d] in /Users/bokken/build/output/Unity-Technologies/mono/mcs/class/corlib/System/ConsoleDriver.cs:57 ```
-
https://github.com/mono/mono/pull/12008/files由 Andrew Spiering 提交于
Pulling in change https://github.com/mono/mono/pull/12008/files which removes the registry as a dependecy for system.xml
-
由 ashwini 提交于
-
由 ashwini 提交于
-
- 30 10月, 2020 2 次提交
-
-
由 Tautvydas Žilys 提交于
Run codesign after otool
-
由 Tautvydas Žilys 提交于
-
- 21 10月, 2020 2 次提交
-
-
由 Jonathan Chambers 提交于
Ensure special static slots respect alignment (case 1266322)
-
由 Jonathan Chambers 提交于
Without proper alignment, this may lead to reference types being stored at non-pointer aligned offsets. Among other issues this may lead to the GC not scanning those pointers properly.
-
- 09 10月, 2020 1 次提交
-
-
由 Tautvydas Žilys 提交于
Fix JIT on macOS Big Sur beta 6 when running on Apple silicon
-
- 07 10月, 2020 8 次提交
-
-
由 Alex Thibodeau 提交于
Wait on runtime threads to park on joinable thread list during shutdown. (case 1275345)
-
由 Tautvydas Žilys 提交于
Sign binaries after lipo-ing them since lipo drops signature added by the linker. Also, use JIT entitlement for signing executables.
-
由 Tautvydas Žilys 提交于
-
由 Tautvydas Žilys 提交于
-
由 ashwini 提交于
Try to copy monodis into monodistribution/bin dir
-
由 ashwini 提交于
-
由 ashwini 提交于
-
由 Alex Thibodeau 提交于
-
- 29 9月, 2020 1 次提交
-
-
由 Alex Thibodeau 提交于
Unity master fix case 1274470
-
- 25 9月, 2020 3 次提交
-
-
由 Alex Thibodeau 提交于
Unity master fix case 1273662
-
由 Zoltan Varga 提交于
Fixes https://github.com/mono/mono/issues/20367. Some light massaging done by @UnityAlex to cherry pick
-
由 lateralusX 提交于
https://github.com/mono/mono/pull/5599 fixed a race condition during shutdown when runtime threads have come parts of their way through detach, but still depend on runtime resources, like GC memory. The fix added runtime threads to the joinable thread list just before they vanished from mono_thread_manage radar making sure shutdown waited upon the thread before cleaning up. The above fix slightly changed the behavior of the finalizer thread since it waits on joinable threads and will now potential block on threads still executing code (that involves runtime resources). There’s was an assumption around the threads on the joinable thread list that they should be very close to complete when added, so join calls coming from the finalizer thread should almost never block and if it does, the code that remains to execute should not involve runtime operations risking deadlock situations. Adding the thread to the list earlier than previously done expose the shutdown to some potential theoretical problems. To mitigate the risk and still solve the race condition this commit adds a mechanism to keep track of active runtime threads until they park on joinable thread list. The pending counter will be waited upon by the shutdown thread, just before it does its regular wait on all joinable threads (after finalizer thread has stopped) to make sure all runtime threads have been added to the joinable thread list before waiting upon them. Threads are added to the joinable thread as late as possible, exactly how it’s been done in the past by sgen_client_thread_detach_with_lock. Shutdown thread will wait on runtime threads to appear on the list for a short time and if timeout (pending runtime thread count not reaching 0 before timeout), it will just print a warning and continue shutdown. Getting into a wait state during shutdown due to runtime threads not yet added to joinable threads list should be very rare (hitting previous race condition that was rare), triggering the timeout should be even more rare, and if that ever happens, we are exposed to shutdown race condition as we have had in the past, but now we at least get a warning in the log making it simpler to analyze further. This commit also fixes a problem with the debugger thread hitting the same race condition as above. The shutdown thread stopping the debugger thread didn't completely wait for it to stop using runtime resources before continue shutdown sequence. This triggers the same race condition as when shutting down regular runtime threads. This commit makes sure stop_debugger_thread waits on the debugger thread handle to become signaled (happens at the very end of thread lifetime) before continuing the shutdown logic.
-
- 23 9月, 2020 1 次提交
-
-
由 Alex Thibodeau 提交于
Remove hack from mono_free_method. Bypassing cleanup here was causing corruption to persist in mscorlib's method hashtable when a rehash occurred. Unity profiler may need changes to avoid possessing dangling pointers. Same with the mono profiler (as the comment indicates)
-
- 22 9月, 2020 3 次提交
-
-
由 Alex Thibodeau 提交于
https://github.com/Unity-Technologies/mono/commit/7869333c52a2fc2d165effefdbbe97fdf9587b57 https://github.com/mono/mono/pull/9863 https://github.com/Unity-Technologies/mono/commit/f265d9a7838c97d33e8836dfc42d1f946de09041 Needed in order to fix corruption that was occuring to mscorlib's image table on domain reload due to dynamic methods from other images being stored in a hashtable that was not being cleaned up on domain reload.
-
由 Joshua Peterson 提交于
The NetworkChange event is not supported on Windows (case 1278048)
-
由 Jonathan Chambers 提交于
Fix performance regression due to ldfld usage by Roslyn (case 1276888)
-
- 21 9月, 2020 1 次提交
-
-
由 Josh Peterson 提交于
Provide a proper `PlatformNotSupported` exception for the `NetworkChange` event on Windows, as it is not currently supported.
-
- 19 9月, 2020 1 次提交
-
-
由 Mathieu Bourgeois 提交于
* Generalize commit 0c6932a9 to support LDARG{0|1|2|3}, LDLOC{0|1|2|3}, LDARGS, LDLOCS, LDARG and LDLOC instead of LDLOC and LDLOCS. Improves generated code similar to issue #60945
-