[x86/Linux] Catch exceptions thrown from unsafe code #7244
Comments
parjong
changed the title
|
\CC @seanshpark |
|
@parjong I think it would be the case for all hardware exceptions. You can try to make a test with null reference or division by zero. using System;
namespace Test
{
public class Program
{
public static void Main(string[] args)
{
string test = null;
Console.WriteLine("NullReferenceException incoming?");
try
{
Console.WriteLine("Hello {0}", test.Length);
}
catch (Exception ex)
{
Console.WriteLine("test.Length threw: {0}", ex);
}
}
}
} |
|
@janvorli There is another issue related with try region (which is almost same as #5676), but that issue seems te be irrelevant. This issue comes from the folloing code in For the above example, the return value of The current implementation does not initialize |
|
@janvorli Here is the result when running the code that you mentioned (it is a bit different from what I expected): |
|
@parjong as I've asked in your other issue, could you please dump the stack trace at the point where you git the sigsegv in EECodeManager::GetGSCookieAddr? There are two possible callers of this method and possibly multiple codepaths that can get you there. |
|
@janvorli Sorry for late response. Here is the stack dump at segfault: At this point, Here is the value of related variables at the frame 2: |
|
@janvorli FYI, here is the prolog of As I understand, it updates GSCookie at |
parjong
referenced
this issue
in parjong/coreclr
Feb 1, 2017
GetGSCookieAddress uses pEbp to get the current frame pointer, but pEbp is not properly initialized as discussed in #8980. This commit revises GetGSCookieAddress to use CallerSp (as in other architectures) to get Frame Pointer in order to fix #8980.
janvorli
referenced
this issue
in dotnet/coreclr
Feb 1, 2017
GetGSCookieAddress uses pEbp to get the current frame pointer, but pEbp is not properly initialized as discussed in #8980. This commit revises GetGSCookieAddress to use CallerSp (as in other architectures) to get Frame Pointer in order to fix #8980.
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
CoreCLR with recent PRs (#8889, dotnet/coreclr#8911, dotnet/coreclr#8913, dotnet/coreclr#8914, dotnet/coreclr#8916, dotnet/coreclr#8964) begins to support exception handling for x86/Linux. (It can run very simple example presented in #7216).
Unfortunately, CLR cannot catch an exception thrown from unsafe code. For example, let us consider the following code:
We except to see the following output for the above code:
Currently, however, we get the following output:
The text was updated successfully, but these errors were encountered: