views:

586

answers:

2

This is code example which causes MarshalDirectiveException. Good explanation of SafeHandles could be found here.


[SuppressUnmanagedCodeSecurity]
private delegate SafeHandle testDelegate();

[SuppressUnmanagedCodeSecurity]
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
public static SafeHandle test(){
    FileStream fs=new FileStream("a.txt", FileMode.Create);
    return fs.SafeFileHandle;
}

private static void Main(){
    MethodInfo methodInfo = typeof (Program).GetMethod("test", BindingFlags.Static | BindingFlags.Public);
    Delegate delegateInstance = Delegate.CreateDelegate(typeof (testDelegate), methodInfo);

    //System.Runtime.InteropServices.MarshalDirectiveException
    //Cannot marshal 'return value': SafeHandles cannot be returned from managed to unmanaged.
    IntPtr fcePtr = Marshal.GetFunctionPointerForDelegate(delegateInstance);

    // alternatively for method parameter
    // throws System.Runtime.InteropServices.MarshalDirectiveException 
    // Cannot marshal 'parameter #1': This type can only be marshaled in restricted ways."

    // alternatively for HandleRef
    // System.Runtime.InteropServices.MarshalDirectiveException
    // Cannot marshal 'parameter #1': HandleRefs cannot be marshaled ByRef or from unmanaged to managed.
}

Simply said, naked handle, received as int or IntPtr could be leaking, when exception is throws before wrapped to appropriate Dipose patter. When returning naked handle to native code, it tends to be g-collected before native code uses the handle. I'm interested to learn how to workaround this problem with enough safety. Specially returning handle worries me. These are just examples for brevity, I don't work with File handle in reality. I would rather like inherit my own from SafeHandle.


[DllImport("mydll")]
public static extern void naked(IntPtr nakedHandle);

private static void Main(){
    IntPtr intPtr = getHandle();
    naked(intPtr);
}

private static IntPtr getHandle(){
    FileStream fs = new FileStream("myfile", FileMode.CreateNew);
    IntPtr ha = fs.Handle;
    return ha;
    // at this point, fs is garbage collected. 
    // ha is pointing to nonexistent or different object.
}

+1  A: 

The typical way to handle this is by pinning the data in the managed code before calling unmanaged functions. Here is an example of pinning data and calling unmanaged calls.

Update: Based on the comment, you could use HandleRef to keep the object reference alive. Then you can still pass the "Handle" to your PInvoke calls. Here is an example that worked for me:

  [DllImport("kernel32.dll", SetLastError=true)]
  static extern bool ReadFile(HandleRef hFile, byte[] lpBuffer,
     uint nNumberOfBytesToRead, out uint lpNumberOfBytesRead, IntPtr lpOverlapped);

  private static HandleRef getHandle()
  {
     FileStream fs = new FileStream("myfile", FileMode.OpenOrCreate, FileAccess.ReadWrite);
     return new HandleRef(fs, fs.SafeFileHandle.DangerousGetHandle());
  }

  private static void Main()
  {
     HandleRef intPtr = getHandle();
     GC.Collect();
     GC.WaitForPendingFinalizers();
     GC.Collect();
     System.Threading.Thread.Sleep(1000);

     const uint BYTES_TO_READ = 10;
     byte[] buffer = new byte[BYTES_TO_READ];
     uint bytes_read = 0;        

     bool read_ok = ReadFile(intPtr, buffer, BYTES_TO_READ, out bytes_read, IntPtr.Zero);
     if (!read_ok)
     {
        Win32Exception ex = new Win32Exception();
        string errMsg = ex.Message;
     }
  }

Almost forgot about clean up here:

  IDisposable is_disposable = intPtr.Wrapper as IDisposable;
  if (is_disposable != null)
  {
     is_disposable.Dispose();
  }
SwDevMan81
I don't have trouble with IntPtr or SafeHandle moving in memory. The problem is that SafeHandle gets disposed early. You could ask me to output FileStream out of getHandle() together with handle. And call some dummy method on fs after I use the handle, to prevent JIT optimizer descope the reference to fs. Sure that works. But it complicates design of any API/library more than acceptable.
Pavel Savara
Ok, that makes sense. I updated my answer. You should be able to change from IntPtr to HandleRef and have it work that same. So "naked" would pass in a HandleRef, and not an IntPtr (like my ReadFile PInvoke method in my example)
SwDevMan81
I guess you could pass in intPtr.Handle instead of changing the method definitions if that will be a pain
SwDevMan81
HandleRef is the correct solution, thanks!Note: it's shame that you could not inherit your strongly typed version from HandleRef. My native API have 3 types of handles, which are not compatible.
Pavel Savara
Actually, that doesn't work with GetFunctionPointerForDelegate as well. :-/System.Runtime.InteropServices.MarshalDirectiveException was unhandledCannot marshal 'parameter #1': HandleRefs cannot be marshaled ByRef or from unmanaged to managed.
Pavel Savara
I think there will be no better solution to this as the functionality is not implemented by Microsoft. I award you because I learned from you about SafeHandle. Cheers.
Pavel Savara
Thanks, glad I could help a little
SwDevMan81
+1  A: 

This is simply a bug, no kind of safe handle is going avoid the .NET wrapper class from getting garbage collected and finalized. It is a pretty common trap in P/Invoke, another classic case is passing a delegate that wraps a callback and forgetting to keep a reference to the delegate object.

Workarounds are easy enough: don't take the Handle until the last possible moment, the garbage collector will see the FS reference on the call stack. Or store the FS in a field of an object that outlives the call. Or P/Invoke DuplicateHandle so the wrapper can be finalized without trouble.

Hans Passant
+1. DuplicateHandle was going to be my answer.
wj32
In my case it's not windows handle but I see your point. But I'm not sure I agree. The SafeHandle owns the reference and reference to SafeHandle is naturally on stack till native method call, because it's passed to marshaller. Therefore it could not disappear. I think that's on of reasons why there is specific handing in marshaller for it.
Pavel Savara
As well, if you duplicate the handle, it will leak handles, because called method generally don't close the handles. That's not good.
Pavel Savara
No, the SafeHandle constructor doesn't take a reference to the object that wraps the handle. It can't keep the object alive. It is only "safe" because the finalizer is guaranteed to run. Yes, if you duplicate the handle then you should call CloseHandle(). The SafeHandle class can do this for you. In a safe way.
Hans Passant