How to get GetFunctionPointerForDelegate for method with SafeHandle or workaround

Question

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.
}

What is intPtr in getHandle()? I dont see where its defined. — SwDevMan81, Jan 10 '10 at 02:02
I think I can help, but I need more information. You want to be able to call a managed function from unmanaged code that takes a handle as it's first argument, correct? Does this call transfer ownership of the handle to the managed code? — Nick Guerrera, Jan 10 '10 at 07:50
@Nick, in most cases not. It just must get something valid (dereference the handle). I will improve my wording. — Pavel Savara, Jan 10 '10 at 08:42
Is your question about the first example or the second? I had assumed the first since that's the part that actually matches the title. Everyone seems to be focusing on the second example in the answers. The two issues are completely different. (1) is about convincing the system to marshal an argument as a SafeHandle during an unmanaged -> managed call. (2) is about ensuring a handle is valid for the duration of managed -> unmanaged call. If I'm reading correctly you want to accomplish (1) and you're providing (2) to make the case that SafeHandle is a _good thing_? Is that right? — Nick Guerrera, Jan 10 '10 at 15:57
@Nick, because 1) doesn't work for me I give 2) to explain broader problem I'm trying to solve. I prefer 1), but have serious doubts it's possible. — Pavel Savara, Jan 10 '10 at 17:28
I don't understand how you can prefer one over the other. (1) will give you a function pointer that unmanaged code can use to "reverse P/Invoke" to managed code and pass a handle. (2) is about passing the handle in the other direction, from managed code to unmanaged code. — Nick Guerrera, Jan 10 '10 at 19:01
Nick, you are right that the example was bit misleading. But you could send handle out as return value when it's incoming call. It doesn't make big difference. I updated the example. — Pavel Savara, Jan 10 '10 at 22:07

score 1 · Accepted Answer · edited May 23 '17 at 12:13

1

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();
  }

edited May 23 '17 at 12:13

Community

1
1

answered Jan 10 '10 at 02:09

SwDevMan81

48,814
22
151
184

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 Jan 10 '10 at 08:48
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 Jan 10 '10 at 14:58
I guess you could pass in intPtr.Handle instead of changing the method definitions if that will be a pain – SwDevMan81 Jan 10 '10 at 15:06
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 Jan 10 '10 at 17:42
Actually, that doesn't work with GetFunctionPointerForDelegate as well. :-/ System.Runtime.InteropServices.MarshalDirectiveException was unhandled Cannot marshal 'parameter #1': HandleRefs cannot be marshaled ByRef or from unmanaged to managed. – Pavel Savara Jan 10 '10 at 18:25
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 Feb 14 '10 at 19:33

score 1 · Answer 2 · answered Jan 10 '10 at 12:16

1

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.

answered Jan 10 '10 at 12:16

Hans Passant

922,412
146
1,693
2,536

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 Jan 10 '10 at 14:07
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 Jan 10 '10 at 14:09
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 Jan 10 '10 at 15:18

How to get GetFunctionPointerForDelegate for method with SafeHandle or workaround

2 Answers2