access violation when linking with VisualStudio 2012 binary

[Wiebke_T_]

Hi!

I compiled and linked an executable (let's call it blah) against a static library (let's call it asdf) that is built with Intel Composer XE 2013 SP1 Update 3 as well as some other static libraries that were built with Visual Studio 2012 (parameters see below).

When I execute blah, I get an access violation out of one of the libraries built with VS2012. (It is a logger library and the error only happens when something is actually printed to stdout). That library was built with the same compiler settings as blah had before its conversion to an Intel compiler solution (except for /Qvc11).

Of course the access violation does not occur when I build the same solution with the Visual Studio compiler, otherwise I wouldn't be writing this post. :)

I suspect that the binaries are somehow incompatible (the access violation happens when I jump OUT of a method that printed a log message).

Am I missing additional compiler options for vc110 compatibility?

--------------------------------------

Here are the details:

The original VS solution of blah had these compiler parameters

/MP /GS /TP /W4 /Zc:wchar_t (various include directories) /Zi /Gm- /O2 /Fd"blah.pdb" /D "WIN32" /D "_WINDOWS" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_WARNINGS" /D "STRICT" /D "NOMINMAX" /D "_VARIADIC_MAX=10" /D "BOOST_ALL_NO_LIB" /D "__WIN32__" /D "__x86__" /D "__NT__" /D "__OSVERSION__=4" /D "NDEBUG" /D "_ITERATOR_DEBUG_LEVEL=0" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /Fa"Release" /EHa /nologo /Fo"blah.dir\Release\" /Fp"blah.dir\Release\blah.pch"  /bigobj

and converted into an Intel compiler solution with these compiler parameters:

/MP /GS /TP /W4 /Zc:wchar_t (various include directories) /Zi /O2 /Fd"blah.pdb" /D "WIN32" /D "_WINDOWS" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_WARNINGS" /D "STRICT" /D "NOMINMAX" /D "_VARIADIC_MAX=10" /D "BOOST_ALL_NO_LIB" /D "__WIN32__" /D "__x86__" /D "__NT__" /D "__OSVERSION__=4" /D "NDEBUG" /D "_ITERATOR_DEBUG_LEVEL=0" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /Zc:forScope /GR /MD /Fa"Release" /EHa /nologo /Fo"blah.dir\Release\" /Fp"blah.pch"  /bigobj  /Qvc11

Here are the linker parameters for blah (they don't change when converting to an Intel C++ solution). Only asdf.lib was built with the Intel compiler as well, all other libs (foo?.lib) were built with Visual Studio 2012. The access violation happens in "badlibrary.lib". (I changed all the names of our own libraries):

/OUT:"blah.exe" /MANIFEST /NXCOMPAT /PDB:"blah.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" "asdf.lib" "badlibrary.lib" "foo0.lib" "gtest.lib" "gtest_main.lib" "chemicaltools.lib" "foo1.lib" "libboost_chrono-vc110-mt-1_55.lib" "foo2.lib" "bdal-sysutils.lib" "foo3.lib" "foo4.lib" "libboost_thread-vc110-mt-1_55.lib" "libboost_date_time-vc110-mt-1_55.lib" "libboost_filesystem-vc110-mt-1_55.lib" "libboost_regex-vc110-mt-1_55.lib" "mkl_intel_lp64.lib" "libboost_system-vc110-mt-1_55.lib" "mkl_sequential.lib" "mkl_core.lib" /STACK:"10000000" /IMPLIB:"blah.lib" /DEBUG /MACHINE:X64 /OPT:REF /INCREMENTAL:NO /PGD:"blah.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"blah.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:(various lib paths) /TLBID:1

[Wiebke_T_]

@Iliyapola: Yes, it compiles, but it crashes at the indicated line at runtime. The compiler settings are further up in this thread...

[Bernard]

I will actually run it .Yesterday only compiled it.

[Bernard]

Compiled program does not crash when I run it on my system.

Can you run your program under windbg and post the call stack here.

[Wiebke_T_]

What is windbg? I used the "Debug" setting of Visual Studio 2012, is that what you wanted me to do?

\edit Ok, I found out about WinDbg. Downloading right now. Will post the stack trace later.

This is with Intel Composer SP1 update 3. We can reproduce the behavior on two independent systems using the compiler from the w_ccompxe_2013_sp1.3.202.exe setup. Are you using a different version?

Here is the stack trace (from the Visual Studio Debugger)

>    msvcp110d.dll!std::basic_streambuf<char,std::char_traits<char> >::setg(char * _First=0x0000000000000000, char * _Next=0x0000000000000000, char * _Last=0x0000000000000000) Line 247    C++
     crashtest.exe!std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_Tidy() Line 348    C++
     crashtest.exe!std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() Line 77    C++
     crashtest.exe!std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream() Line 544    C++
     crashtest.exe!std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> >::`vbase destructor'(void)    C++
     crashtest.exe!boost::optional_detail::optional_base<std::ostringstream>::destroy_impl(boost::mpl::bool_<0>={...}) Line 479    C++
     crashtest.exe!boost::optional_detail::optional_base<std::ostringstream>::destroy() Line 440    C++
     crashtest.exe!boost::optional_detail::optional_base<std::ostringstream>::assign(int *=0xccccccccffffffff) Line 313    C++
     crashtest.exe!boost::optional<std::ostringstream>::operator=(int * none_=0x000007feffffffff) Line 616    C++
     crashtest.exe!test() Line 9    C++
     crashtest.exe!main() Line 15    C++
     crashtest.exe!__tmainCRTStartup() Line 536    C
     crashtest.exe!mainCRTStartup() Line 377    C
     kernel32.dll!0000000076f759ed()    Unknown
     ntdll.dll!RtlUserThreadStart()    Unknown

Again here are my compiler options (for executing the toy example in a project of its own):

/MP /GS /TP /W4 /Zc:wchar_t /I"D:/boost/1.55/include" /Zi /Od /Fd"E:/Projects/MyProject/build/bin/myapp/win32-x86_64-vc110/Debug/crashtest.pdb" /D "WIN32" /D "_WINDOWS" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_WARNINGS" /D "STRICT" /D "NOMINMAX" /D "_VARIADIC_MAX=10" /D "BOOST_ALL_NO_LIB" /D "__WIN32__" /D "__x86__" /D "__NT__" /D "__OSVERSION__=4" /D "_DEBUG" /D "_ITERATOR_DEBUG_LEVEL=1" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /Zc:forScope /RTC1 /GR /MDd /Fa"Debug" /EHa /nologo /Fo"crashtest.dir\Debug\" /Fp"crashtest.dir\Debug\crashtest.pch"  /bigobj

My colleague used these options (by creating a project with solution->New->Project in Visual Studio) and got the crash as well:

/GS /W3 /Zc:wchar_t /I"E:\Development\boost\1.55\include" /ZI /Od /Fd"Debug\vc110.pdb" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Zc:forScope /RTC1 /Gd /MDd /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\IntelCompilerTest.pch"

[Wiebke_T_]

Ok, I found and ran WinDbg, and I can assure you that the call stack looks identical appart from formatting. (And it doesn't support copying of text).

[Bernard]

I would prefer to look at windbg output if it is possible.

You can set in windbg break on access violation exception with this command sxe av.

What i would like to see is register contexts and faulting Instruction Pointer. Btw , you can copy and paste debugger output into text file and upload it here.

[Bernard]

 >>>msvcp110d.dll!std::basic_streambuf<char,std::char_traits<char> >::setg(char * _First=0x0000000000000000, char * _Next=0x0000000000000000, char * _Last=0x0000000000000000) Line 247    C++>>>

I assume that this code point is source of the crash.What really puzzles me are the setg() function arguments which have null value.

[Wiebke_T_]

Ok, I found a "copy stack to clipboard" in the menu... I'm not familiar with windbg. Thanks for the hint with sxe av :)

Here is the complete stack trace:

 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 00000000`00b2f698 00000001`3f607c75 : 00000000`00b2f9e8 00000000`00000000 00000000`00000000 00000000`00000000 : MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x22
01 00000000`00b2f6a0 00000001`3f605ca7 : 00000000`00b2f9e8 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_Tidy(void)+0x12d
02 00000000`00b2f730 00000001`3f60819a : 00000000`00b2f9e8 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf(void)+0x5f
03 00000000`00b2f770 00000001`3f60b956 : 00000000`00b2f9e0 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream(void)+0x86
04 00000000`00b2f7b0 00000001`3f609b93 : 00000000`00b2f9e0 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!std::basic_ostringstream<char,std::char_traits<char>,std::allocator<char> >::`vbase destructor'+0x4e
05 00000000`00b2f7e0 00000001`3f6098fe : 00000000`00b2f950 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!boost::optional_detail::optional_base<std::ostringstream>::destroy_impl(void)+0x63
06 00000000`00b2f820 00000001`3f609820 : 00000000`00b2f950 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!boost::optional_detail::optional_base<std::ostringstream>::destroy(void)+0x5e
07 00000000`00b2f860 00000001`3f60937b : 00000000`00b2f950 cccccccc`ffffffff cccccccc`cccccccc cccccccc`cccccccc : crashtest!boost::optional_detail::optional_base<std::ostringstream>::assign(void)+0x4c
08 00000000`00b2f890 00000001`3f60bc30 : 00000000`00b2f950 000007fe`ffffffff 00000000`00000000 cccccccc`cccccccc : crashtest!boost::optional<std::ostringstream>::operator=(int * none_ = 0x000007fe`ffffffff)+0x4f
09 00000000`00b2f8c0 00000001`3f60bd0c : cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!test(void)+0x11c
0a 00000000`00b2fa60 00000001`3f60ce1d : 00000001`00000001 00000001`3f612388 00000000`00000000 00000001`3f60df06 : crashtest!main(void)+0x3e
0b 00000000`00b2fa90 00000001`3f60cf4e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : crashtest!__tmainCRTStartup(void)+0x19d
0c 00000000`00b2fb00 00000000`76f759ed : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : crashtest!mainCRTStartup(void)+0xe
0d 00000000`00b2fb30 00000000`7766c541 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
0e 00000000`00b2fb60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

What puzzles me is that you don't get the crash. What is different in your setup?
Maybe it depends on the CPU what the compiler produces? It's Intel Xeon X5570 with Windows 7 Ultimate (x64-bit) here. I could package and send the compiled binary if that helps.

The compiler may have a problem with correctly managing the lifetime of the object but the details aren't clear to me.

[Bernard]

  >>>crashtest.exe!std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_Tidy() >>>

Can you post the actual arguments of quoted function?

[Bernard]

@Wiebke

Thanks for posting the callstack I will look at it today later.

[Bernard]

Stack looks very strange.It seems that stream of 0xcc instructions overflow part of the stack.Could cc stand for some kind of ASCII char?Anyway it is really strange.

I would like to ask you to dump exception context with .ecxr command and post the faulting IP with register context.This could shed more light on the exact code point of the access violation.

[Wiebke_T_]

This is all I got...

(f68.1b10): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\MSVCP110D.dll -
MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x22:
000007fe`f02624b2 488908          mov     qword ptr [rax],rcx ds:00000000`00000006=????????????????
*** WARNING: Unable to verify checksum for crashtest.exe
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
0:000> .ecxr
Unable to get exception context, HRESULT 0x8000FFFF

What do you mean with "faulting IP"?

I attached the register content when the debugger stops for the exception.

[Bernard]

Thanks for posting that info.

>>>MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x22:

000007fe`f02624b2 488908          mov     qword ptr [rax],rcx ds:00000000`00000006=????????????????>>>

The quoted text is so called faulting IP .It seems that rcx register is loaded with invalid virtual memory address(00000000`00000006).In order to find the culprit backtracing must be done going backward from this IP 000007fe`f02624b2. Putting it simply we must find how  and by whom rcx register was loaded.It can be done by using these commands: ub 000007fe`f02624b2  and uf std::basic_streambuf<char,std::char_traits<char> >::setg. By looking at setg() function declaration it seems that this function receives three char pointers.I think that aferementioned pointer(s) is this one 00000000`00b2f9e8.I see that this pointer points to statically allocated buffer on the stack.I suppose that volatile rcx is overwritten at setg+0x22 code location and probably the previous caller is responsible for not preserving registers.

[Marián__VooDooMan__M]

@iliyapolak

Yes, you are (mostly) right, but MSVC uses Intel assembler syntax and not AT&T, so in my opinion RCX register is not loaded from that virtual address, but stored to mentioned virtual address.

But this is only cosmetic issue in your post

[Bernard]

That code is moving (copying) value stored in RCX  into  referenced memory address in [RAX]. 

http://en.wikipedia.org/wiki/MOV_(x86_instruction)

[Marián__VooDooMan__M]

iliyapolak wrote:

That code is moving (copying) value stored in RCX  into  referenced memory address in [RAX]. 

Exactly, that was what I was saying. I had impression you were saying the opposite. Just a misunderstanding on my side of your post.

Anyway, your post is valuable IMHO, for resolving the issue, and I respect your WinDbg knowledge (I use it only in case of kernel crash to see what driver/device is probably faulty and so I know only command "!analyze -v", so I regard your post to learn from it, to get much better understanding WinDbg, even though there are URLs like http://windbg.info/doc/1-common-cmds.html ...). I'm just used to MSVC IDE debugger.

[Bernard]

@Marian

Thank you :)

I am still learning the arcane art of debugging.

You can check this website http://blogs.msdn.com/b/ntdebugging/

and this one http://web.archive.org/web/20110726011358/http://www.dumpanalysis.org/

[Bernard]

@Wiebke

Can you collect dump file and upload it?

[Wiebke_T_]

@Iliyapolak and Marian: Thanks for the interesting discussion and links.

0:000> ub 000007fe`f00a24b2
MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setbuf+0x1f:
000007fe`f00a248f cc              int     3
MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg:
000007fe`f00a2490 4c894c2420      mov     qword ptr [rsp+20h],r9
000007fe`f00a2495 4c89442418      mov     qword ptr [rsp+18h],r8
000007fe`f00a249a 4889542410      mov     qword ptr [rsp+10h],rdx
000007fe`f00a249f 48894c2408      mov     qword ptr [rsp+8],rcx
000007fe`f00a24a4 488b442408      mov     rax,qword ptr [rsp+8]
000007fe`f00a24a9 488b4018        mov     rax,qword ptr [rax+18h]
000007fe`f00a24ad 488b4c2410      mov     rcx,qword ptr [rsp+10h]

0:000> uf std::basic_streambuf<char,std::char_traits<char> >::setg
Couldn't resolve error at 'std::basic_streambuf<char,std::char_traits<char> >::setg'

I attached a (zipped) dump file that I created with the task manager after the program stopped with the first change access violation.

Wouldn't it be easier if you reproduced the problem (using the same compiler version) on your side? :)

[Bernard]

>>>Wouldn't it be easier if you reproduced the problem (using the same compiler version) on your side? :)>>>

I cannot reproduce the access violation on my pc.

I will look at dump file and post the results.

[Bernard]

>>>0:000> uf std::basic_streambuf<char,std::char_traits<char> >::setg

Couldn't resolve error at 'std::basic_streambuf<char,std::char_traits<char> >::setg'>>>

If this function will not be resolved further debugging will  be impossible.