CODEWITHSUNDEEP
c++cmemorymemory-managementshared-libraries
lagarkane
lagarkane

Reputation: 1005

Where is allocated my memory in a dynamically loaded library?

I have been wondering for a while.. According to this table: http://ilay.org/yann/articles/mem/process_map.png (sorry for the french part of it) memory is allocated in different memory spaces depending on which part of the program is allocating it.

Thus, if I create an object in my program, it will be allocated in the program. If allocate memory dynamically, it will be in the heap , and the "links" for the dynamically loaded objects.

My question is: Where does the memory dynamically allocated from the dynamically loaded libaries belong?

if I have library that contains this:

extern "C" Object* create_Object()
{
   return new Object();
}

class Object
{
    int a;
    int* b;
    ...
}

Will my object be allocated in the heap or in the links?

My guess would be the heap, but I have a piece of code that makes me doubt it. I am developing a Cpp script system, where my scripts are compiled as shared libraries, loaded into my program, and reloaded everytime a script has to be recompiled. The idea is to save the state of my scripts before unloading them, and restore their content in the new instance of the dynamically loaded object. If the fields of my dynamically loaded object are mapped in the heap, save the pointer to the data is enough, but if the created class is allocated in the "links" segment of memory, then when I restore the content, my pointers will point on unallocated memory, which will make my program totally unstable, which is the case...

So I don't know. where in the memory is my instance of "Object"? where is "a", that is not dynamically allocated? and where would "b"'s content if I allocate it dynamically, in my example?

I would expect that new allocates in the heap no matter where the new is called, and that the variable a and b from Object would be allocated in the heap too, since it is instanciated from a dynamically allocated object, but it is only speculations and I would like to know it for sure...

I also wonder what happen to my Object instance once I dlclose my shared library. once again if it is in the heap, I should not have any problem to acces my object, but since I don't have the symbols, I guess the object would be allocated but quite unsuable since I would not be able to resolve its members.

I hope you can help me with that =)

Upvotes: 4

Views: 1937

Answers (2)

rslemos
rslemos

Reputation: 2731

I think the object data is safely stored on the heap, even after dlclose() (unless C++ dynamic space allocator is changed).

But surely you'll have a problem calling virtual methods. The virtual table will point to a text area no longer available. And C++ does not provide means to rebind virtual methods; not that I know.

If you really need to, you can:

  1. change your class definition to struct;
  2. declare all virtual methods as pointers inside this struct;
  3. have your load/unload routine provide the binding (that is, assigning each real function for each pointer in each allocated object).

Of course you'll have track all object instances. And of course you can have a single pointer, pointing to a table, the table itself provided by the library; this single pointer must still be manually rebound though.

Upvotes: 3

ach
ach

Reputation: 2373

There is no such thing as memory dynamically allocated from the dynamically loaded libaries. Memory allocated dynamically means it is allocated with a call to malloc. There's only one malloc in your program, and it is of no importance whether the call to it comes from the part of the program code which was loaded with your original executable or with a shareable object file.

Note: from practical perspective, new is typically implemented via a call to malloc, therefore, the same consideration applies here.

Note, that on Win32 the situation may be quite different: a DLL may have its unique malloc (and, of course, free) operating on its own heap. Memory malloc'd in such a DLL must then be free'd in the same DLL.

Upvotes: 3

Related Questions