Hi,
Try valgrind or create a small test-case and attach it to a bug report at
bugzilla.ximian.com.
Zoltan
On 8/25/07, Sebastian Good <[EMAIL PROTECTED]> wrote:
> I have not attempted to run a memory profiler on my example, but the
> brute-force method of letting the code run in a loop causes t
I have not attempted to run a memory profiler on my example, but the
brute-force method of letting the code run in a loop causes the process to
eventually run out of memory. What is the recommended way to debug these
leaks? On the suspicion it was actually just the managed copy of the input
string
Hi,
The input parameter is converted by the runtime from ut8 to a managed string
object, which is handled by the GC, so there should be no leak there. The result
is converted from a managed string object to ut8, and the caller should free it
using g_free (). S
Thanks, I've read (and now-reread!) this fairly carefully, but my case is
about C code calling CLI code, not the other way around, so I do not see
explicit instructions about things like, for instance, how to treat the
char* returned from the managed delegate. I would have expected the copy of
the
Hi,
Try our interop tutorial. It has some answers to your questions.
http://www.mono-project.com/Interop_with_Native_Libraries
Zoltan
On 8/25/07, Sebastian Good <[EMAIL PROTECTED]> wrote:
> Thanks to help on this list I've come a long way in embedding mono into my
> C++ application
Thanks to help on this list I've come a long way in embedding mono into my
C++ application. During the transition of a very large application (25+ yrs
of C, Fortran, & C++) towards managed code, we will be adding new code in
.NET languages, but needing to access these objects from C++ fairly
intim
