Discussion:
Memory Issues on P/Invoke
(too old to reply)
Fábio Chicout
2010-02-02 13:33:46 UTC
Permalink
Does anyone know if Marshal.GetDelegateForFunctionPointer have some memory
issues?

This is what's happening. I'm with some DLL's that are used with
interoperability on a C# project and in a Java Project. The Java project
calls the functions exposed on the native DLL's many, many times (50 times
on 15 minutes). And no problem is seen.

When we are using the C# app that uses the native DLL's, on the 5th time the
same function is called, it's thrown an Exception saying that the memory was
corrupted.

This can be for the runtime environment (.NET Framework vs. JVM)? What can I
do to debug this? (I thought on a profiler, but I've only found a free
profiler that do not tells 'bout memory consumed, but time spend on each
method - and I haven't acess to a VSTS to use the integrated profiler).

Thanks in advance,
Fábio Chicout
Jeroen Mostert
2010-02-02 21:51:15 UTC
Permalink
Post by Fábio Chicout
Does anyone know if Marshal.GetDelegateForFunctionPointer have some
memory issues?
Not unless you introduce them.

For starters, do your really need to call .GetDelegateForFunctionPointer()?
This is tricky stuff that's only required if you really need to pass around
dynamic function pointers. If all you're interested in is calling a function
statically exported from a DLL, don't muck around with pointers and use
[DllImport] declarations.
Post by Fábio Chicout
When we are using the C# app that uses the native DLL's, on the 5th time
the same function is called, it's thrown an Exception saying that the
memory was corrupted.
Try running the project with MDAs (Managed Debugging Assistants) turned on
to detect problems (see http://msdn.microsoft.com/library/d21c150d).
However, many things could be going wrong in calling the function, not all
detectable with MDAs. Without seeing actual code, it's impossible to tell.
Post by Fábio Chicout
This can be for the runtime environment (.NET Framework vs. JVM)? What
can I do to debug this? (I thought on a profiler, but I've only found a
free profiler that do not tells 'bout memory consumed, but time spend on
each method - and I haven't acess to a VSTS to use the integrated
profiler).
Profilers are not debuggers. While you can use an unmanaged debugger like
WinDbg to see what's going wrong, doing this for interop scenarios requires
a good understanding of assembly and is not for the faint of heart. You're
better off having a thorough understanding of P/Invoke and getting the
declarations right -- it's very unlikely that the problem is with the
runtime mechanism and all the more likely it's with your declarations.
--
J.
Ben Voigt [C++ MVP]
2010-02-18 19:21:59 UTC
Permalink
Post by Fábio Chicout
Does anyone know if Marshal.GetDelegateForFunctionPointer have some
memory issues?
This is what's happening. I'm with some DLL's that are used with
interoperability on a C# project and in a Java Project. The Java
project calls the functions exposed on the native DLL's many, many
times (50 times on 15 minutes). And no problem is seen.
When we are using the C# app that uses the native DLL's, on the 5th
time the same function is called, it's thrown an Exception saying
that the memory was corrupted.
It's your responsibility to make sure that the delegate isn't deleted by the
garbage collector (store it in a static field, use GCHandle, or whatever but
keep it reachable). The GC can't see what managed objects are used in
native code so you have to keep them alive yourself.
Post by Fábio Chicout
This can be for the runtime environment (.NET Framework vs. JVM)?
What can I do to debug this? (I thought on a profiler, but I've only
found a free profiler that do not tells 'bout memory consumed, but
time spend on each method - and I haven't acess to a VSTS to use the
integrated profiler).
Thanks in advance,
Fábio Chicout
MarkusSchaber
2010-02-19 09:27:05 UTC
Permalink
Hi,
Post by Ben Voigt [C++ MVP]
It's your responsibility to make sure that the delegate isn't deleted by the
garbage collector (store it in a static field, use GCHandle, or whatever but
keep it reachable).  The GC can't see what managed objects are used in
native code so you have to keep them alive yourself.
Is it necessary to "pin" delegates (as it is with normal objects), to
prevent them from being relocated by the garbage collector?

Markus

Loading...