| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* Remove all uses of CanRunManagedCode()
|
|
* Remove more MDA support code
* PR Feedback
|
|
* Add EntryPointFilter
|
|
|
|
|
|
* Show the expected stack trace from a rethrown exception.
Fix #15780
* Remove now unused methods
- StackTraceArray::AppendSkipLast
- StackTraceElement::PartiallyEqual
- StackTraceElement::PartialAtomicUpdate
|
|
https://github.com/dotnet/coreclr/commit/16fc3005c085212f6e700a0df8ff7f36c1ea535b
The PR was trying to fix an incorrect test , we should be passing
in !fForWinRT.See https://github.com/dotnet/coreclr/issues/13460#issuecomment-324456870
for more info.
|
|
from the VM (#12389)
* Remove inclusions of private handle table headers from the VM
* Add TraceRefCountedHandles to the GC handle table interface
* Fix the Unix build
* Move ValidatePinnedObject to marshalnative.h
|
|
|
|
|
|
|
|
During the exception handling pass 1 on Unix, we only find one holder for each
frame. But for the case where there are multiple scopes embedded in each other,
each of them having their own exception holder, this is not correct and we
need to call filters for all holders on such frame, starting from the inner-most
one.
This change fixes that.
In addition, it fixes one usage of the EX_CATCH_CPP_ONLY in the src/vm/threads.cpp
where the presence of the exception holder in the EX_TRY is not correct and causes
the exception handler pass 1 to consider the managed exception handled at that place.
The fix is to create a new EX_TRY_CPP_ONLY that doesn't contain the holder and use
it at that place.
In fact, the comment at EX_CATCH_IMPL_CPP_ONLY was suggesting that a separate EX_TRY
clone would be a better solution anyways, since it eliminates one try / catch level
in the EX_CATCH_IMPL_CPP_ONLY.
|
|
(Interop\WinRT\Exception\ManagedClientNativeServer\ExceptionTest.csproj).
The test checks that the HResult 0x8000000e maps to a System.InvalidOperationException.
What was happening: We returned a System.COMException with the message "A method was called at an unexpected time." (we're just constructing an exception based on an HR message).
What should be happening: We return a System.InvalidOperationException (i.e. we check against the exceptionKind maps for a specific HResult to map to an exception).
The point of failure is in the creation of the EEMessageException. When calling GetKindFromHR(...) we were inverting the boolean that uses the WinRT mappings.
Removing that inversion allows us to check the WinRT Exception Maps for exceptions. When I made this change, we correctly return the correct Exception.
Test coverage: I ran a full DDR, and the whole TOF (both against my build and against the newest build). All passed successfully (i.e. no additional failures).
[tfs-changeset: 1514327]
|
|
[tfs-changeset: 1407945]
|
