access violation when linking with VisualStudio 2012 binary

access violation when linking with VisualStudio 2012 binary

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

 

72 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Can you post call stack?

Hello,

Does this only happens with update3 and no problem with SP1 compiler fomer updates ?

>>>The access violation happens in "badlibrary.lib". >>>

So av happens inside your own library?

@iliyapolak: Hard to say where the access violation happens. It occurs when it jumps OUT of our own library. It is a std c++ library. Before the exception occurs, the debugger jumps back and forth between lines, so somehow, when jumping out of the "badlibrary" function, it messes up the stack pointer I think. Below is a stack frame from when it jumps out of the method for the first time (and steps onto one line BEFORE the line where it goes wrong. (The stack is from a gtest where I did nothing except that library call. There is no multithreading, so it cannot legally step BACKWARDS in the code.)

@QIAOMIN Q: I don't know, I haven't tried with the former updates. Do you think it is worth to reinstall an old one? I used the newest because  I need VS2012 compatibility.

...um.... the forum software says my submission contains invalid characters, so I'm trying without the call stack at first... will try with next post.

 

---- call stack -----

> formulascoringtests.exe!boost_optional_detail::boost_optional_detail::() Line 42 C++ msvcr110d.dll!_CallSettingFrame() Line 51 Unknown msvcr110d.dll!__FrameUnwindToState(unsigned __int64 * pRN=0x00000000009baef8, _xDISPATCHER_CONTEXT * pDC=0x00000000009bb0c0, const _s_FuncInfo * pFuncInfo=0x000000014245f9d0, int targetState=-1) Line 1064 C++ msvcr110d.dll!__FrameUnwindToEmptyState(unsigned __int64 * pRN=0x00000000009bafe0, _xDISPATCHER_CONTEXT * pDC=0x00000000009bb0c0, const _s_FuncInfo * pFuncInfo=0x000000014245f9d0) Line 158 C++ msvcr110d.dll!__InternalCxxFrameHandler(EHExceptionRecord * pExcept=0x00000000009bc3b0, unsigned __int64 * pRN=0x00000000009bafe0, _CONTEXT * pContext=0x00000000009bb1b0, _xDISPATCHER_CONTEXT * pDC=0x00000000009bb0c0, const _s_FuncInfo * pFuncInfo=0x000000014245f9d0, int CatchDepth=0, unsigned __int64 * pMarkerRN=0x0000000000000000, unsigned char recursive='\0') Line 393 C++ msvcr110d.dll!__CxxFrameHandler3(EHExceptionRecord * pExcept=0x00000000009bc3b0, unsigned __int64 RN=10220864, _CONTEXT * pContext=0x00000000009bb1b0, _xDISPATCHER_CONTEXT * pDC=0x00000000009bb0c0) Line 193 C++ ntdll.dll!RtlpExecuteHandlerForUnwind () Unknown ntdll.dll!RtlUnwindEx () Unknown kernel32.dll!000000007785050e() Unknown msvcr110d.dll!__C_specific_handler(_EXCEPTION_RECORD * ExceptionRecord=0x00000000009bc3b0, void * EstablisherFrame=0x00000000009bf710, _CONTEXT * ContextRecord=0x00000000009bbec0, _DISPATCHER_CONTEXT * DispatcherContext=0x00000000009bb870) Line 212 C ntdll.dll!RtlpExecuteHandlerForException () Unknown ntdll.dll!RtlDispatchException () Unknown ntdll.dll!KiUserExceptionDispatch () Unknown msvcp110d.dll!std::ios_base::_Ios_base_dtor(std::ios_base * _This=0x00000000009bf720) Line 41 C++ msvcp110d.dll!std::ios_base::~ios_base() Line 533 C++ msvcp110d.dll!std::basic_ios >::~basic_ios >() Line 40 C++ formulascoringtests.exe!std::basic_ostringstream, std::allocator >::~basic_ostringstream() Line 543 C++ msvcr110d.dll!_CallSettingFrame() Line 51 Unknown msvcr110d.dll!__FrameUnwindToState(unsigned __int64 * pRN=0x00000000009bc648, _xDISPATCHER_CONTEXT * pDC=0x00000000009bc810, const _s_FuncInfo * pFuncInfo=0x0000000142ac4698, int targetState=-1) Line 1064 C++ msvcr110d.dll!__FrameUnwindToEmptyState(unsigned __int64 * pRN=0x00000000009bc730, _xDISPATCHER_CONTEXT * pDC=0x00000000009bc810, const _s_FuncInfo * pFuncInfo=0x0000000142ac4698) Line 158 C++ msvcr110d.dll!__InternalCxxFrameHandler(EHExceptionRecord * pExcept=0x00000000009bdb00, unsigned __int64 * pRN=0x00000000009bc730, _CONTEXT * pContext=0x00000000009bd010, _xDISPATCHER_CONTEXT * pDC=0x00000000009bc810, const _s_FuncInfo * pFuncInfo=0x0000000142ac4698, int CatchDepth=0, unsigned __int64 * pMarkerRN=0x0000000000000000, unsigned char recursive='\0') Line 393 C++ msvcr110d.dll!__CxxFrameHandler3(EHExceptionRecord * pExcept=0x00000000009bdb00, unsigned __int64 RN=10220368, _CONTEXT * pContext=0x00000000009bd010, _xDISPATCHER_CONTEXT * pDC=0x00000000009bc810) Line 193 C++ ntdll.dll!RtlpExecuteHandlerForUnwind () Unknown ntdll.dll!RtlUnwindEx () Unknown kernel32.dll!000000007785050e() Unknown msvcr110d.dll!__C_specific_handler(_EXCEPTION_RECORD * ExceptionRecord=0x00000000009bdb00, void * EstablisherFrame=0x00000000009bf710, _CONTEXT * ContextRecord=0x00000000009bd610, _DISPATCHER_CONTEXT * DispatcherContext=0x00000000009bcfc0) Line 212 C ntdll.dll!RtlpExecuteHandlerForException () Unknown ntdll.dll!RtlDispatchException () Unknown ntdll.dll!KiUserExceptionDispatch () Unknown msvcp110d.dll!std::basic_ostream >::~basic_ostream >() Line 87 C++ formulascoringtests.exe!std::basic_ostringstream, std::allocator >::~basic_ostringstream() Line 543 C++ msvcr110d.dll!_CallSettingFrame() Line 51 Unknown msvcr110d.dll!__FrameUnwindToState(unsigned __int64 * pRN=0x00000000009bdcf8, _xDISPATCHER_CONTEXT * pDC=0x00000000009bdec0, const _s_FuncInfo * pFuncInfo=0x0000000142ac4698, int targetState=-1) Line 1064 C++ msvcr110d.dll!__FrameUnwindToEmptyState(unsigned __int64 * pRN=0x00000000009bdde0, _xDISPATCHER_CONTEXT * pDC=0x00000000009bdec0, const _s_FuncInfo * pFuncInfo=0x0000000142ac4698) Line 158 C++ msvcr110d.dll!__InternalCxxFrameHandler(EHExceptionRecord * pExcept=0x00000000009bf1b0, unsigned __int64 * pRN=0x00000000009bdde0, _CONTEXT * pContext=0x00000000009be6c0, _xDISPATCHER_CONTEXT * pDC=0x00000000009bdec0, const _s_FuncInfo * pFuncInfo=0x0000000142ac4698, int CatchDepth=0, unsigned __int64 * pMarkerRN=0x0000000000000000, unsigned char recursive='\0') Line 393 C++ msvcr110d.dll!__CxxFrameHandler3(EHExceptionRecord * pExcept=0x00000000009bf1b0, unsigned __int64 RN=10220368, _CONTEXT * pContext=0x00000000009be6c0, _xDISPATCHER_CONTEXT * pDC=0x00000000009bdec0) Line 193 C++ ntdll.dll!RtlpExecuteHandlerForUnwind () Unknown ntdll.dll!RtlUnwindEx () Unknown kernel32.dll!000000007785050e() Unknown msvcr110d.dll!__C_specific_handler(_EXCEPTION_RECORD * ExceptionRecord=0x00000000009bf1b0, void * EstablisherFrame=0x00000000009bf710, _CONTEXT * ContextRecord=0x00000000009becc0, _DISPATCHER_CONTEXT * DispatcherContext=0x00000000009be670) Line 212 C ntdll.dll!RtlpExecuteHandlerForException () Unknown ntdll.dll!RtlDispatchException () Unknown ntdll.dll!KiUserExceptionDispatch () Unknown msvcp110d.dll!std::basic_streambuf >::setg(char * _First=0x0000000000000000, char * _Next=0x0000000000000000, char * _Last=0x0000000000000000) Line 247 C++ formulascoringtests.exe!std::basic_stringbuf, std::allocator >::_Tidy() Line 348 C++ formulascoringtests.exe!std::basic_stringbuf, std::allocator >::~basic_stringbuf() Line 77 C++ formulascoringtests.exe!std::basic_ostringstream, std::allocator >::~basic_ostringstream() Line 544 C++ formulascoringtests.exe!std::basic_ostringstream,class std::allocator >::`vbase destructor'(void) C++ formulascoringtests.exe!boost::optional_detail::optional_base::destroy_impl(boost::mpl::bool_={...}) Line 479 C++ formulascoringtests.exe!boost::optional_detail::optional_base::destroy() Line 440 C++ formulascoringtests.exe!boost::optional_detail::optional_base::~optional_base() Line 268 C++ formulascoringtests.exe!boost::optional::~optional() Line 567 C++ formulascoringtests.exe!bdal::logging::LoggerStream::~LoggerStream() Line 221 C++ formulascoringtests.exe!boost_optional_detail::boost_optional_detail::() Line 45 C++ formulascoringtests.exe!testing::internal::HandleSehExceptionsInMethodIfSupported(testing::Test * object=0x0000000000bdb590, void (void) * method=0x000000013fe6bb30, const char * location=0x000000014249fda8) Line 2063 C++ formulascoringtests.exe!testing::internal::HandleExceptionsInMethodIfSupported(testing::Test * object=0x0000000000bdb590, void (void) * method=0x000000013fe6bb30, const char * location=0x000000014249fda8) Line 2114 C++ formulascoringtests.exe!testing::Test::Run() Line 2157 C++ formulascoringtests.exe!testing::TestInfo::Run() Line 2330 C++ formulascoringtests.exe!testing::TestCase::Run() Line 2445 C++ formulascoringtests.exe!testing::internal::UnitTestImpl::RunAllTests() Line 4316 C++ formulascoringtests.exe!testing::internal::HandleSehExceptionsInMethodIfSupported(testing::internal::UnitTestImpl * object=0x0000000000baaee0, bool (void) * method=0x000000013fe4b690, const char * location=0x000000014249e7c8) Line 2063 C++ formulascoringtests.exe!testing::internal::HandleExceptionsInMethodIfSupported(testing::internal::UnitTestImpl * object=0x0000000000baaee0, bool (void) * method=0x000000013fe4b690, const char * location=0x000000014249e7c8) Line 2114 C++ formulascoringtests.exe!testing::UnitTest::Run() Line 3929 C++ formulascoringtests.exe!RUN_ALL_TESTS() Line 2289 C++ formulascoringtests.exe!main(int argc=1, char * * argv=0x0000000000baa7e0) Line 38 C++ formulascoringtests.exe!__tmainCRTStartup() Line 536 C formulascoringtests.exe!mainCRTStartup() Line 377 C kernel32.dll!00000000778359ed() Unknown ntdll.dll!RtlUserThreadStart () Unknown

Hi,

     Can you please compile using "/Qcheck-pointers" option to check if there are any bounds violation? You can find more details about this option here :-

https://software.intel.com/sites/products/documentation/doclib/iss/2013/... 

Please be noted that this option has some overhead!!

Regards,

Sukruth H V 

I don't see any difference when compiling with /Qcheck-pointers. I don't get any "Debug Assertion Failed!" message during runtime. Actually, the behavior does not change at all. (Which I get when I deliberately insert a line that accesses out of bounds, so the compiler option is definitely active.)

Interestingly, calls into the other VS2012-compiled libraries work: The problematic library is a (lazy) logging library, and all unit tests work correctly if nothing is logged. I will try to drill down when exactly this behavior occurs.

 

 

@Wiebke T

Can you upload call stack as text file?

 

@Wiebke

In your case running your program under windbg could be more helpful in finding access violation exception.Debugger will break-in on av occurrence.

It could be code related access violation or data related.

Hi,

      As stated /Qcheck-pointers would be helpful to detect the OOB overflows at the runtime. So i just wanted you to try this option to see if there are any OOB's.

It would be helpful to further investigate on this issue, if you can provide me a simple testcase.

Regards,

Sukruth H V

Dear all,I tried /Qcheck-pointers and it does NOT trigger when I run under debug. So there is no out of bounds or any other check assertion. (Also remember that the same call works flawlessly under gcc 4.8 and vc110). The behavior in debug configuration is similar to that in release configuration, just the places where the current line jumps after leaving said call differs.

The colleague who maintains the library is trying to find the root cause. He suspects it may have to do with how the icc treats temporaries.

This test reproduces the problem (thanks to my colleague Daniel for figuring this out):

//---------------------------------------------
#include <sstream>
#include "boost/optional.hpp"

void test()
{
  boost::optional<std::ostringstream> os_;
  os_ = boost::in_place();
  (*os_) << "Hu!" << std::flush;
  os_ = boost::none; // Crash here
}

int main()
{
  test();
}

 

It happens when this is compiled with the composer, it's not a VS2012 compatibility issue.

 

Can we change the title, please? This has nothing to do with Visual Studio...

Same issue here, started happening after I updated to XE SP1 Update 3. I use VS2013, the latest version.

> msvcr120.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 628 crt0dat.c

onexitbegin_new = (_PVFV *) DecodePointer(__onexitbegin);

__onexitbegin is not a valid pointer.

I should also note that I use external libraries, and the issue only occurs with optimization enabled.

It looks like an issue is related to msvcr120.dll library.

>>>__onexitbegin is not a valid pointer>>>

Is this message thrown by msvcr120.dll library code?

@Evgeni

Did you encode __onexitbegin with EncodePointer() function?

http://msdn.microsoft.com/en-us/library/bb432242(v=vs.85).aspx

@Evgenii: I'm not sure this is the "same issue"...

@iliyapolak: Any feedback on the code snippet I posted?

 

@Wiebke

Today I will try to reproduce your issue.

test-case from the post #13

@Iliyapolak: Thank you! Didn't mean to hurry you up, just wanting to make sure the thread doesn't go astray to other (even if related) issues :)

 

@Wiebke

My test case compiles fine either in debug build or in release build.

1>------ Build started: Project: IDZ_test3, Configuration: Release Win32 ------
1>  stdafx.cpp
1>  IDZ_test113.cpp
1>  xilink: executing 'link'
1>  IDZ_test3.vcxproj -> c:\users\bernard\documents\visual studio 2013\Projects\IDZ_test3\Release\IDZ_test113.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

Can you post your compiler settings?

 

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

 

I will actually run it .Yesterday only compiled it.

 

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.

 

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"

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).

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.

 

 >>>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.

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 [D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sstream @ 348]
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 [D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sstream @ 77]
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 [D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sstream @ 544]
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 [D:\boost\1.55\include\boost\optional\optional.hpp @ 479]
06 00000000`00b2f820 00000001`3f609820 : 00000000`00b2f950 cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!boost::optional_detail::optional_base<std::ostringstream>::destroy(void)+0x5e [D:\boost\1.55\include\boost\optional\optional.hpp @ 440]
07 00000000`00b2f860 00000001`3f60937b : 00000000`00b2f950 cccccccc`ffffffff cccccccc`cccccccc cccccccc`cccccccc : crashtest!boost::optional_detail::optional_base<std::ostringstream>::assign(void)+0x4c [D:\boost\1.55\include\boost\optional\optional.hpp @ 313]
08 00000000`00b2f890 00000001`3f60bc30 : 00000000`00b2f950 000007fe`ffffffff 00000000`00000000 cccccccc`cccccccc : crashtest!boost::optional<std::ostringstream>::operator=(int * none_ = 0x000007fe`ffffffff)+0x4f [D:\boost\1.55\include\boost\optional\optional.hpp @ 616]
09 00000000`00b2f8c0 00000001`3f60bd0c : cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc cccccccc`cccccccc : crashtest!test(void)+0x11c [E:\Projects\blah\src\crashtest\crash.cpp @ 13]
0a 00000000`00b2fa60 00000001`3f60ce1d : 00000001`00000001 00000001`3f612388 00000000`00000000 00000001`3f60df06 : crashtest!main(void)+0x3e [E:\Projects\blah\src\crashtest\crash.cpp @ 19]
0b 00000000`00b2fa90 00000001`3f60cf4e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : crashtest!__tmainCRTStartup(void)+0x19d [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c @ 536]
0c 00000000`00b2fb00 00000000`76f759ed : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : crashtest!mainCRTStartup(void)+0xe [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c @ 377]
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.

 

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

Can you post the actual arguments of quoted function?

 

 

@Wiebke

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

 

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.

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.

Attachments: 

AttachmentSize
Downloadtext/plain registers_0.TXT2.16 KB

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.

@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

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

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

Quote:

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.

@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/

@Wiebke

Can you collect dump file and upload it?

@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? :)

Attachments: 

AttachmentSize
Downloadapplication/zip crashtest.zip2.31 MB

>>>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.

>>>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.

It seems that symbol server does not have MSVCP110D pdb file or it is loading incorrect pdb file.

We don't use a symbol server. I provided the path to the pdb file of the executable. There are no .pdb files where that MSVCP110D library is. I don't know where to get it. Google didn't help...

Any ideas?

 

I have MSVCP110D.AMD64.PDB file on my system it was downloaded from the public server and probably this is the reason for that error.I also did search on the Google but it was not helpful.

There is one workaround for this problem.I will try to dump the raw stack around call to setg() function and try to see if that function pushed its return address on the stack.If it did I could go backward until  hitting the faulting address.

I will inform you about the progress.

 

Great, thanks!
 

Later I will post an update.

@Wiebke

I managed to unassembled back that faulty function and now I am trying to understand what caused access violation error.

Can you run this code under windbg and use step-in functionality?

Alright... I set a breakpoint at line 13 of crash.cpp and then stepped in until the access violation. I attached the cmd window output.

Attachments: 

AttachmentSize
Downloadtext/plain StepInto_1.txt17.75 KB

Thanks I am trying to understand the cause.

I think that these lines of code are critical

MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x14:
000007fe`eecd24a4 488b442408      mov     rax,qword ptr [rsp+8] ss:00000000`00b3f870=0000000000b3fbb8
0:000> t
MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x19:
000007fe`eecd24a9 488b4018        mov     rax,qword ptr [rax+18h] ds:00000000`00b3fbd0=0000000000000006
0:000> t
MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x1d:
000007fe`eecd24ad 488b4c2410      mov     rcx,qword ptr [rsp+10h] ss:00000000`00b3f878=0000000000000000
0:000> t
MSVCP110D!std::basic_streambuf<char,std::char_traits<char> >::setg+0x22:
000007fe`eecd24b2 488908          mov     qword ptr [rax],rcx ds:00000000`00000006=????????????????

Can you resolve what this address contains 0000000000b3fbb8 ?On my analysis I get uninitialized memory

0:000> dds 0000000000b3fbb8
00000000`00b3fbb8  ????????

 

It seems that this address 00000000`00b3f878 is the argument of the setg function.I think that this address 0000000000b3fbb8  contains null pointer value and next 0x18 bytes are added in this instruction  mov     rax,qword ptr [rax+18h] ds:00000000`00b3fbd0=0000000000000006 resulting in RAX containing the value of 0x6.Now look at this buffer address and the value of RSP+0x10:

mov     qword ptr [rsp+10h],rdx ss:00000000`00b3f878=cccccccccccccccc

mov     rcx,qword ptr [rsp+10h] ss:00000000`00b3f878=0000000000000000

Pay attention that RSP+10h was not modified between these two calls.

 

In this line   of code originates this buffer address 0000000000b3fbb8 and seems that this is inside destructor function.

crashtest!std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf+0x53:
00000001`3fef5c9b 488b4520        mov     rax,qword ptr [rbp+20h] ss:00000000`00b3f940=0000000000b3fbb8

I think that MSVCP110D code is accessing freed memory. I need confirmation from you. You can do it by running this command !address 00000000`00b3fbb8 .

Pages

Leave a Comment

Please sign in to add a comment. Not a member? Join today