c++ Dll export static memeber

This topic is 3029 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hello i have the following example a.h:
class a
{
DLLAPI static type member;
}

a.cpp:
type a::member = 0;

DLLAPI is __declspec(dllexport) or __declspec(dllimport) i have an project which includes the dll. The problem is that when i try to access the static member ; i Get Unhandled exception at 0x003552ae (Library.exe) in Test.exe: 0xC0000005: Access violation reading location 0x00441408. Any help would be appreciated. Thanks, Raxvan.

Share on other sites
You need to give more detail. What is type? Give the code that attempts to access the static member.

Share on other sites
Given the example type is a*
Also to show exactly what happens: The following code creates the error:
a.h
namespace b{class a{public:      DLLAPI static a* member;};DLLAPI void foo();};

a.cpp
using namespace b;b::a* b::a::member = 0;void b::foo(){    if(a::member==0)// this is where i get the error    {    }}

Error happens when i import the Dll and call foo.I can go with the debugger inside foo.So i think foo is called properly.
Also i import the dll by using #pragma comment(lib,"...dllname.lib")

Thanks,
Raxvan

Share on other sites
I can't see anything wrong with that code, and it works fine for me. Are you sure it's a valid simplification of your real failing case?

It seems strange that it's linking all the symbols correctly (implicit linking, right?) and successfully invoking b::foo, but not liking b::a::member.

Have you tried a rebuild all (CTRL+ALT+F7 in MSVS), to rebuild both the DLL and application projects?

Are you building both projects in debug mode, so that the source code line information that's used to show where the exception occurs is correct? Is it really crashing due to another statement nearby?

If you're still stuck you could post relevant sections of the actual code you're having trouble with, if you can.

Share on other sites
I have cleaned the solution and rebuilt everything in Debug. It didn't work.

The thing is, that my code is a replica of an architecture from another code. There everything seemed to work perfectly. What i didn't mentioned earlier is that the Dll isn't actually a Dll , is a ConsoleApplication which exports stuff.
On the original code this worked. The interesting thing is that when i compile my code a Dll this time, not a .exe, i didn't get the error and the code worked perfectly. I can only suppose that i forgot to take a closer look to the build settings of the original project in order to see if something from there would make this work.

So i got it to work ok by recompiling into a dll.This isn't the solution i preferred :) but it will work just fine.

Thanks,
Raxvan.

Share on other sites
Quote:
 Original post by MakaanWhat i didn't mentioned earlier is that the Dll isn't actually a Dll , is a ConsoleApplication which exports stuff.

Ah, that would have been good to know beforehand :)

What is most likely happening is that your two executables have the same base address (MSVS's default is always 0x00400000), and Windows' loader is rebasing the module with b::a::member in it. (You can see if this is the case by looking in MSVS's 'Modules' debug window - rebased modules have a little exclamation mark on their icon).

However, your application module is not being built with an .idata import section for symbols from this other module, like b::foo. Hence the call to b::foo is actually jumping control to somewhere unknown, and dying a gruesome death soon after. (Try looking at where EIP goes in the debugger when you call b::foo, ignoring the source code view.)

Share on other sites
Yes indeed i get the same address for the .exe files.
Unfortunately i don't understand exactly what happens when going with the debugger in disassembly mode. As far as i understood calling b::foo is jumping somehow outside the exe's memory space.

Thanks anyway :),

Raxvan.