7 replies to this topic

[feel_energetic]

can the DLL access the heap area of another dynamic lib or static lib?
why is the pointer treated uninitialized(memory already allocated in fact) when accessing by a DLL?

for example, I have a global pointer g_pObject defined in static library kernel.lib
and a global GFunc() which access g_pObject (also in kernel.lib)

When application is initialized, I allocate a memory block in the heap for it
after that, if GFunc() is called in a DLL, it will crash when accessing g_pObject in GFunc()
the value of g_pObject is 0x00000000 (not initialized yet)

In fact, I use Loki::SingletonHolder to build a singleton instead of using global pointer
it's the final run-time behavior that Loki::SingletonHolder allocates the object twice,

1. at the first time the singleton is accessed in kernel.lib
2. at the first time the singleton is accessed by DLL

Can someone help me to solve this problem?
Thanks very much!

[monjardin]

Yes, the DLL could access the memory if it wasn't getting a null pointer. It sounds like you have initialization problems. Are you allocating the memory in a static variable initialization?

Try allocating the memory and setting the pointer in main instead and see if that fixes the problem.

I've found these issues to be enough of a pain in the ass to stop using cute singleton implementations. The fact of the matter is that if you were to allocate this memory after main, and then pass the pointer to the DLL function - without using static globals - then you wouldn't have this problem.

I hoped that helped. There are other more knowledgeable people around if it didn't. ;)

[feel_energetic]

thanks for your help :)

I did step into the code to check where is the memery allocated
both of them are allocated at the first time being accessed (of course after the main() entry )

let me make it clearer

1. The pointer g_pObject is declared and initialized as NULL (in global scope of a static library kernel.lib)
2. allocate memory for g_pObject when the application is initialized
3. perform some operation on it ( g_pObject->DoSomeTask() )
4. after a while, a GFunc() defined in kernel.lib (which may perform operations many times on g_pObject ) is called in a DLL
5. at this time, it crashes when accessing g_pObject in GFunc()

My question is: can the DLL call GFunc() to perform the same operations on g_pObject, like it does in kernel.lib?


hope it's clearer this time:)

[Reedbeta]

It sounds to me like your static library, kernel.lib, is being linked into both the main application and the DLL. If this is the case, you will get two different copies of g_pObject (and everything else in the static library). So perhaps what is happening is that GFunc() is doing its work on the wrong copy of g_pObject - one that hasn't been initialized!

On the other hand, if you are actually passing the g_pObject from the application to the DLL, e.g. as a parameter to a function call, then there should be no problem.

[feel_energetic]

oh i got it
that's what i guessed
you mean the DLL will make a local copy of "everything in the static library"
does "everything" here means "all exported symbol" or "all data content"?

why should they be copied
and further more, does this copy-rule work in any other case?
so wonderful if you would like to explain a little more :)

[Reedbeta]

All data content (at least, all that is used by your application or DLL). Not just data, but code. All the code that your DLL calls, and all data that the called code in the library refers to.

The whole idea of a static library is that everything in it gets copied into whatever you link it into. Linking to a static library is basically like adding all the source code of that library into your project. The point is to be able to distribute the resulting executable without needing to distribute a copy of the library.

If you want a variable to be shared between multiple modules, then it has to be in a DLL, which is a shared library - the same code (and data) accessed by (potentially) multiple callers. Or better yet, just create the object in the main application and pass a pointer to it into the DLL.

[feel_energetic]

thanks for your explanation:)

[Alex]

You gotta be careful about deallocation though. As the the dll has its own heap trying to free something that was allocated in the main app inside the dll will cause a runtime error. If you pass objects across dll boundaries you can solve that by making the destructor virtual.