possible bug with icl 13.1.3.198 Build 20130607 (and for quite a few versions now)

[Dan_Saalfeld]

I'm having a very odd issue with some class variables being exported by a DLL.  It boils down to this:

If I declare multiple variables of a class on a single line e.g.  

__declspec(dllexport) SomeClass var1, var2; 

I see the ctors and dtors called more than twice.

If however I declare them on separate lines e.g.

__declspec(dllexport) SomeClass var1;

__declspec(dllexport) SomeClass var2;

Everything works fine as expected... I see 2 ctor and 2 dtor calls.  

This becomes an issue when SomeClass contains say a std::list in which case the extra dtor throws an exception on program exit.

Attached is a basic example of the issue. To build the version with odd behavior:

icl foo.cpp /LD /EHsc /DBAD_VERSION

icl main.cpp foo.lib /MD /EHsc /DBAD_VERSION

Then run main.exe. Output should look like:

ctor
ctor
ctor
inserting 3
inserting 1
dtor
dtor (CRASH)

To build the version that runs ok:

icl foo.cpp /LD /EHsc

icl main.cpp foo.lib /MD /EHsc

Then run main.exe. Output should look like:

ctor
ctor
inserting 3
inserting 1
dtor
dtor

Just as expected.

Obviously I can go through all our projects and change the declarations, but that seems kind of silly.. unless I am missing something?

Thanks,

Dan 

[Casey]

I cannot reproduce this behavior on Linux with icpc version 13.1.3 20130607.  I replicated your environment --compiled foo.cpp as a shared library containing the globally scoped classes and then dynamically linked the resulting library with main.cpp.  Whether I define BAD_VERISON or not, I get the output:

[bash]

$ ./icpctest
ctor
ctor
inserting 3
inserting 1
dtor
dtor

[/bash]

I can reproduce the ctor and dtor being called twice each, but only if I mis-declare the class instances such that both the library and the executable think they own the global objects. Does icl contain its own linker on windows or does it it use the MSVC linker?  Google turns up a hit or two with similar bugs in MSVC and I wonder if this isn't a problem with dynamic linking and the windows dll mechanisms.  I don't have a windows box to test on, so I can only speculate.

For reference, the changes I made to your code to compile on Linux were in include.h:

[cpp]

#ifdef _EXPORT
#define DLL_EXTERN 
#else
#define DLL_EXTERN extern
#endif

[/cpp]

and my compiler invocation was:

[bash]

$ icpc -DBAD_VERSION -shared -g -fPIC -Wl,-soname,libtest-icpc.so.1 -o libtest-icpc.so.1.0.1 foo.cpp

$ icpc -DBAD_VERSION -g -Wl,-rpath,/home/casey/code/icpctest -o icpctest main.cpp -L. -ltest-icpc

[/bash]

[JenniferJ]

with VS2010 and icl 13.1.3.198, it works with icl for both ia32 and x64.

are you using vs2008?

Jennifer

[Dan_Saalfeld]

Yes we are using vs2008 : Microsoft (R) Incremental Linker Version 9.00.30729.01

I thought it had worked with icl version 12.0.4.196  which was why I thought it could be an icl issue.  However after double checking on a coworker's machine I am even more confused as both versions of the test case crash, but our actual project seems to work just fine.  

[SergeyKostrov]

There is a problem with how you've declared these variables in the "Include.h" header file. In overall, you don't need to use DLL_EXTERN again and a C keyword extern needs to be used instead ( the declaration in the header should not create instances for both objects (!) ). Actual declarations of these two variables need to be in foo.cpp class. The __declspec(dllexport) and __declspec(dllimport) are fundamental keywords and they were introduced in 1994 or so. I use similar declarations since then for classes declared in DLLs and I don't see any problems with Intel and Microsoft C++ compilers.