4

I was reading that all a process's memory is released by the OS when the process terminates (by any means) so negating the need to call every dtor in turn.

Now my question is how does the memory of a DLL or SO relate to clean up of alloc'd memory?

I ask because I will probably end up using a Java and/or C# to call into a C++ DLL with some static C style functions which will allocate the C++ objects on the heap. Sorry if I got carried away with the heap vs stack thread, I feel I have lost sight of the concept of _the_ heap (ie only one).

Any other potential pitfalls for memory leaks when using libraries?

John
  • 6,433
  • 7
  • 47
  • 82

2 Answers2

1

There is nothing for you to worry about. The operating system's loader takes care of this.

In general, shared libraries will be made visible to your process's address space via memory mapping (all done by the loader), and the OS keeps track of how many processes still need a given shared library. State data that is needed separately per process is typically handled by copy-on-write, so there's no danger that your crypto library might accidentally be using another process's key :-) In short, don't worry.

Edit. Perhaps you're wondering what happens if your library function calls malloc() and doesn't clean up. Well, the library's code becomes part of your process, so it is really your process that requests the memory, and so when your process terminates, the OS cleans up as usual.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
1

The library becomes part of the process when it is loaded. Regarding tidy up of memory, handles, resources etc., the system doesn't distinguish whether they were created in the executable image or the library.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490