Question

I have a quite strange problem:

I am testing several function calls to a unmanaged C dll with NUnit. The odd thing is, the test fails when it runs normally, but when i run it with the debugger (even with no break point) it passes fine.

So, has the debugger a wider memory access as the plain NUnit application?

i have isolated the call which fails. its passing back a char pointer to a string, which the marshaller should convert to a C# string. the C side looks like this:

#define get_symbol(a) ((a).a_w.w_symbol->s_name)
EXTERN char *atom_get_symbol(t_atom *a);

...

char *atom_get_symbol(t_atom *a) {
  return get_symbol(*a);
}

and the C# code:

[DllImport("csharp.dll", EntryPoint="atom_get_symbol")]
[return:MarshalAs(UnmanagedType.LPStr)]
private static extern string atom_get_symbol(IntPtr a);

the pointer which is returned from c is quite deep inside the code and part of a list. so do i just miss some security setting?

EDIT: here is the exception i get:

System.AccessViolationException : (translated to english:) there was an attempt to read or write protected memory. this might be an indication that other memory is corrupt.

at Microsoft.Win32.Win32Native.CoTaskMemFree(IntPtr ptr)
at ....atom_get_symbol(IntPtr a)

SOLUTION:

the problem was, that the marshaller wanted to free the memory which was part of a C struct. but it sould just make a copy of the string and leave the memory as is:

[DllImport("csharp.dll", EntryPoint="atom_get_symbol")]
private static extern IntPtr atom_get_symbol(IntPtr a);

and then in the code get a copy of the string with:

var string = Marshal.PtrToStringAnsi(atom_get_symbol(ptrToStruct));

great!

Answer 1

This will always cause a crash on Vista and up, how you avoided it at all isn’t very clear. The stack trace tells the tale, the pinvoke marshaller is trying to release the string buffer that was allocated for the string. It always uses CoTaskMemFree() to do so, the only reasonable guess at an allocator that might have been used to allocate the memory for the string. But that rarely works out well, C or C++ code almost always uses the CRT’s private heap. This doesn’t crash on XP, it has a much more forgiving memory manager. Which produces undiagnosable memory leaks.

Notable is that the C declaration doesn’t give much promise that you can pinvoke the function, it doesn’t return a const char*. The only hope you have is to declare the return type as IntPtr instead of string so the pinvoke marshaller doesn’t try to release the pointed-to memory. You’ll need to use Marshal.PtrToStringAnsi() to convert the returned IntPtr to a string.

You’ll need to test the heck out of it, call the function a billion times to ensure that you don’t leak memory. If that test crashes with an OutOfMemoryException then you have a big problem. The only alternative then is to write a wrapper in the C++/CLI language and make sure that it uses the exact same version of the CRT as the native code so that they both use the same heap. Which is tricky and impossible if you don’t have the source code. This function is just plain difficult to call from any language, including C. It should have been declared as int atom_get_symbol(t_atom* a, char* buf, size_t buflen) so it can be called with a buffer that’s allocated by the client code.