Fixing Memory leaks in C code accessed via JNI

Question

Hi,
I am working on an JNI interface between Java and legacy C code and I have problems with controlling the Memory inside the C code. In my application, I call many times from Java the C routines. In the C routines, memory is allocated but in a rather unclear and sloppy
way. Not all memory is return after the C code finishes and I cannot go inside the code and release the memory block using free(). As a consequence, after a couple of runs all memory is consumed. Nevertheless, I know that all memory allocated in the C program should be available again after the C routine has finished.
Is there a trick available that, for example, I can release all claimed memory by the C program before returning to Java, so the next time a C routine is called from Java, all free memory is again available for the C routine?
Perhaps unloading the DLL and reloading the DLL before each C routine (how to do?).
Or keeping track of the memory pointer before entering the C code and force it back to that position (freeing the claimed memory) after finishing the C code part (how to do?).

Answer 1

Presumably you know that the correct way is to fix the C code?
Maybe or mabe not...thinking out loud here...(and you need to check everything I say, since I am not doing the research, just pulling it out of my head.)
The only way to do what you want is to dig deep, deep into the OS and compiler.
Each process on the OS allocates a stack and a heap (this is not the java heap) to the process when it starts.
You could then take a snap shot of the heap before starting. Then on exit you would free anything that wasn't in use when you started.
However, your java app uses the same heap, so if you have any threads then it won't work. But you always have more than one thread, for instance the garbage collector. You could of course hack the jvm source to suspend all the threads (C suspension not java) to solve that problem.
But you can't make any java method calls in your C code without doing the snap shot thing again. And I would bet that comparing the post and pre snap shots is going to take a while.
Alternatively I do know that dlls use (or maybe used to use) either their own heap or their own stack. If it is the heap then at least the time problem won't be as much.
I think there is also a way to replace the heap. This might be easy or hard. And either way it is probably dangerous. But if you did that then you would never have to worry about the snap shot comparison. Just throw away the new heap when you are done (give it back to the OS.)
You might want to really look at that C code to. C programmers tended to use global variables a lot and initialize them in routines like
static void* mylocal =0;
void doit() { if (!mylocal) mylocal = malloc(sizeof(something)); }
And if that occurs anywhere then switching heaps or deleting snap shots is probably not going to work.