DLL / SO library, how does library memory relate to the calling process?

Question

I read that all operating memory is freed by the OS when the process terminates (in any way), which negates the need to call each dtor in turn.

Now my question is: how is DLL or SO memory related to alloc'd memory cleanup?

I ask because I probably end up using Java and / or C # to invoke a C ++ DLL with some static C-style functions that will allocate C ++ objects on the heap. Sorry, if I got carried away by the heap and stack flow, I feel like I have lost sight of the concept of the _the_ heap (that is, only one).

Any other potential memory leak problems using libraries?

Answer 1

A library becomes part of the process when it is loaded. As for the accumulation of memory, pens, resources, etc., the system does not distinguish whether they were created in an executable image or in a library.

Answer 2

You have nothing to worry about. The bootloader will take care of this.

In general, shared libraries will be displayed in the address space of your process using memory mapping (all executed by the loader), and the OS keeps track of how many processes are still required for this shared library. The state data that is required separately for each process is usually processed by copying to write, so there is no danger that your crypto library may accidentally use a different process key :-) In short, do not worry.

Change You might be wondering what happens if the library function calls malloc() and is not cleared. Well, the library code becomes part of your process, so your process actually requests memory, so when your process terminates, the OS is cleaned up as usual.