2

I'm currenty doing micro-benchmarks for a better understanding of clr to native code performance. In the following example I'm getting a StackOverflowException, when compiled as release and executed without debugger attached. I don't get the exception when compiling as debug-build or when running the program with debugger attached. Furthermore I also get this error only with SuppressUnmanagedCodeSecurityAttribute-Attribute.

I built a dll using c and VS2013 (platformtoolset=v120) with one function in it:

__declspec(dllexport) int __cdecl NativeTestFunction(int a, int b, int c, int d)
{
    return a + c + b + d;
}

In my C#-program I use DllImport to call this function and do some timing-measurements:

[DllImport("Native.dll", EntryPoint = "NativeTestFunction")]
static extern int NativeTestFunction(int a, int b, int c, int d);

[DllImport("Native.dll", EntryPoint = "NativeTestFunction"), SuppressUnmanagedCodeSecurityAttribute]
static extern int NativeTestFunctionSuppressed(int a, int b, int c, int d);

static void Main(string[] args)
{
    byte[] data = new byte[64];
    int c = 0;

    Stopwatch sw = Stopwatch.StartNew();

    for (int i = 0; i < 10000000; i++)
        c += NativeTestFunction(2, -1, -2, 1);

    Console.WriteLine("Unsuppressed: " + sw.Elapsed.ToString());
    sw = Stopwatch.StartNew();

    for (int i = 0; i < 10000000; i++)
        c += NativeTestFunctionSuppressed(2, -1, -2, 1);

    Console.WriteLine("Suppressed..: " + sw.Elapsed.ToString());
}

If I compile this code as release and start it without debugger attached the output is:

Unsuppressed: 00:00:00.2666255

Process is terminated due to StackOverflowException.

However, executed with debugger attached or compiled as debug and launched with or without debugger attached the program succeeds:

Unsuppressed: 00:00:00.2952272
Suppressed..: 00:00:00.1278980

Is this a known Bug in .NET/CLR? What is my mistake? I think the behavior should be the same between attached and not-attached debugger.

This error happens with .NET 2.0 and .NET 4.0. My software is compiled as x86 (and therefore tested only for x86) for compatibility to the Native.dll. If you don't want to setup this scenario yourself you can download my test-projects: Sourcecode.

Matthias
  • 948
  • 1
  • 6
  • 25
  • 1
    Your declaration is wrong, the missing CallingConvention = CallingConvention.Cdecl unbalances the stack. Yes, that will easily bomb when you run the Release build without a debugger and the code optimizer can do its magic. You should have gotten a warning about that, do make sure you did not turn off the PInvokeStackImbalance debugger assistant off. – Hans Passant Jun 09 '15 at 14:01
  • Sorry for the duplicate. While asking i didn't know that __cdecl/__stdcall was the problem. – Matthias Jun 09 '15 at 14:14

1 Answers1

5
__declspec(dllexport) int __cdecl NativeTestFunction(int a, char* b, int c, int d)

Note the type of b. It is char*. Then in the C# code you write:

[DllImport("Native.dll", EntryPoint = "NativeTestFunction"), 
    SuppressUnmanagedCodeSecurityAttribute]
static extern int NativeTestFunctionSuppressed(int a, int b, int c, int d);

Here you declare b to be int. That does not match. It gets worse when you call the function.

NativeTestFunctionSuppressed(2, -1, -2, 1);

Passing -1 will, in a 32 bit process, equate to passing the address 0xffffffff. Nothing good will come of attempting to de-reference that address.

The other problem is that the calling conventions do not match. The native code uses __cdecl, but the managed code uses the default of __stdcall. Change the managed code to:

[DllImport("Native.dll", EntryPoint = "NativeTestFunction", 
    CallingConvention = CallingConvention.Cdecl), 
    SuppressUnmanagedCodeSecurityAttribute]

And likewise for the other import.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490