I've reduced my case as much as possible below.
#include <vector>
#include <atomic>
#include <chrono>
using namespace std;
class Unused
{
private:
vector<vector<unsigned>> data;
atomic<unsigned> counter;
};
class Timer
{
private:
chrono::time_point<chrono::high_resolution_clock> begin;
public:
void start()
{
begin = std::chrono::high_resolution_clock::now();
}
};
int main()
{
Unused unused;
vector<Timer> timers;
timers.resize(1);
timers[0].start();
}
I've compiled it as (note the specific flags):
cl /O2 /GL /EHsc driver.cpp
This is with
Microsoft (R) C/C++-Optimierungscompiler Version 19.27.29111 für x86
Microsoft (R) Incremental Linker Version 14.27.29111.0
but I've tried a couple of other recent versions as well. The executable segfaults with a memory access violation. It works with g++, and it works if I change the compile flags. It also works is I simplify the code further.
Is this a compiler bug?
It was indeed a compiler bug, https://developercommunity.visualstudio.com/content/problem/1157189/possible-compiler-bug-1.html.
Related
I have found a strange behavior (probably an issue) while trying to compile a simple application with MS VC 15.3.1 (after applying VC 2017 Upgrade 3):
#include <iostream>
#include <algorithm>
#include <string>
// compiles if commenting out the line below
#include <vector>
#include <list>
class A
{
std::string s;
public:
A(const std::string& str) : s(str)
{
}
A(A&& other)
{
// compiles if changing std::swap<std::string>() to std::swap()
std::swap<std::string>(s, other.s);
}
};
int main(int argc, char *argv[])
{
return 0;
}
the compiler emits error :
1>d:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.11.25503\include\vector(2131):
error C2039: '_Alloc': is not a member of 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>'
This code compiles without any issues with VC 15.2, VS2015 and VS2013 toolsets.
so somewhere along the lines of putting this app together I've started to get a runtime check failure stack corruption when the destructor for a cstring class member is called.
I've gotten to the point of trying to debug this by throwing bricks at the issue but still havent root caused it. At the current moment the class that the cstring resides in does nothing but initialize its private string members and set a pointer to another class to NULL.
Interestingly if I do not set the class pointer to NULL and comment out that line the corruption goes away. I think this is somewhat of a red herring, and that something is changing in the way the compiler is putting the code together when it pulls in the .h file that contains theCLog definitions and that would be used since I'm declaring a pointer to that object.
int _tmain(int argc, _TCHAR* argv[])
{
DWORD a = 0xBABA; //just to help catch the corrupter
DWORD b = 0xDFDF;
CStringW startat = L"\\\\anetworkshare\\fre";
CStringW lookfor = L".inf";
DirEnum myEnum(startat,lookfor);
ULONG en = a + b;
en = a - b;
return 0;
}
DirEnum.cpp
DirEnum::DirEnum(CString startingdir,CString fileFilter)
{
m_plogfile = NULL; //If you comment out this line corruption goes away
m_startingdir = L"";
m_extfilter = L"";
if(startingdir.GetLength() > 0)
m_startingdir = startingdir;
if(fileFilter.GetLength() > 0)
m_extfilter = fileFilter;
//following commented out to tshoot
//CLogBase& ref = ref.GetInstance();
//logBase = &ref;
//m_plogfile = new CLog(L"DirEnumerator",L"logfile.txt",logINFO);
}
Now I suspect that something in the log.h file is causing a change to occuur in the ATL or CString libraries but I dont know what. Heres the log.h file
#pragma once
//#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
#ifndef UNICODE
#define UNICODE
#endif
#ifndef _UNICODE
#define _UNICODE
#endif
using namespace std;
#ifndef TYPEDEF_H
#define TYPEDEF_H
#include <string>
#include <sstream>
#include <iostream>
#include <fstream>
#include <tchar.h>
#include <time.h>
//simple defines to allow the TCHAR library to be used
typedef std::basic_string<TCHAR> tstring;
typedef std::basic_ostream<TCHAR> tostream;
typedef std::basic_istream<TCHAR> tistream;
typedef std::basic_ostringstream<TCHAR> tostringstream;
typedef std::basic_istringstream<TCHAR> tistringstream;
typedef std::basic_ofstream<TCHAR> tofstream;
#if defined(UNICODE) || defined(_UNICODE)
#define tcout std::wcout
#define tcin std::wcin
#else
#define tcout std::cout
#define tcin std::cin;
#endif
#endif
#if defined DEBUG || defined (_DEBUG)
#define TOCONSOLE
#endif
typedef enum LOGLVL{logERROR =0,logWARN,logINFO,logDEBUG};
//CLogBase os a singleton log class. Intent is that you can establish a reference from anywhere in the project and write to the same file
// without having locking issues or threading issues
class CLogBase
{
public:
static CLogBase& GetInstance(CString logname = L"log.txt",LOGLVL lvl = logWARN);
~CLogBase(void);
tostringstream& GetLog(LOGLVL level);
tostringstream& GetStream(LOGLVL);
void Forceflush();
private:
CLogBase(CString file,LOGLVL lvl);
//our outstream
tostringstream m_os;
tostringstream m_dummy;
tofstream m_filestream;
CString m_filename;
LOGLVL m_reportlvl;
//Private declarations to prevent copy constructors from being invoked; these are do nothig implimentations
CLogBase(CLogBase const&);
void operator=(CLogBase const&);
};
class CLog
{
public:
CLog(CString component);
CLog(CString component,CString logname,LOGLVL lvl);
~CLog();
void Log(LOGLVL,CString message);
void CLog::Flush();
tostringstream& CLog::GetStream(LOGLVL lvl);
private:
CString m_componentname;
CLogBase* m_logBase;
};
I thought I would answer this as I found the issue. this was not a coding problem per se but a visual studio issue.
What happened was that I was storing the direnum.h file and .cpp file in a different directory than the one used for the main project. referencing the header with #include "..\somedir\direnum.h"
at one point in time visual studio reported the file as locked and did I want to overwrite \ cancel etc. I choose overwrite but what seemed to happen was that this caused VS to COPY the files to the current project. All my troubleshooting attempts were being edited in the local somename.h file whtne opened in the editor but the compiler was doing the correct thing and pulling down the .h file from the location above.
removing switching to the now local copy of direnum.h and recompiling fixed this as it was compiling part of the code as ANSI and the other part as WCHAR
How msvc11 can compile printf("msvc"); with only <iostream> header?
#include <iostream>
using namespace std;
int main()
{
printf("test123");
cin.get();
return EXIT_SUCCESS;
}
No error...
msvc11
For Visual Studio 2013, iostream includes istream which includes ostream which includes ios which includes xlocnum which includes cstdio which includes stdio.h. It's just standard header file spill-over.
I have a problem lunching a thread within a class A for example where the class A is a static member of class B with in a dll. I am using Visual Studio 9 and boost 1.40. Please consider the following code:
mylib.h:
#include <boost/thread.hpp>
#include <windows.h>
#ifdef FOO_STATIC
#define FOO_API
#else
#ifdef FOO_EXPORT
#define FOO_API __declspec(dllexport)
#else
#define FOO_API __declspec(dllimport)
#endif
#endif
class FOO_API foo{
boost::thread* thrd;
public:
foo();
~foo();
void do_work();
};
class FOO_API bar{
static foo f;
public:
static foo& instance();
};
mylib.cpp:
#include "mylib.h"
foo::foo()
{
thrd = new boost::thread(boost::bind(&foo::do_work,this));
}
foo::~foo(){
thrd->join();
delete thrd;
}
void foo::do_work(){
printf("doing some works\n");
}
foo& bar::instance(){return f;}
foo bar::f;
in the executable application, I have:
main.cpp:
#include "mylib.h"
void main(){
bar::instance();
}
If I link mylib statically to the executable app, It prints out "doing some works", while if I link it dynamically (dll), it does nothing.
I really appreciate any help.
Your program could be exiting before the thread completes. You might try waiting after the bar::instance() call, or joining the thread in main. Something else to try would be to flush stdout after the printf call.
From the MSDN documentation:
If your DLL is linked with the C
run-time library (CRT), the entry
point provided by the CRT calls the
constructors and destructors for
global and static C++ objects.
Therefore, these restrictions (*) for
DllMain also apply to constructors and
destructors and any code that is
called from them.
(*) The restrictions include communicating with threads.
It's best to make the global variable a pointer, and construct and release the object in dedicated callback routines.
See also this helpful SO answer.
The program below crashes when I build it in Release x64 (all other configurations run fine).
Am I doing it wrong or is it an OpenMP issue?
Well-grounded workarounds are highly appreciated.
To reproduce build a project (console application) with the code below.
Build with /openmp and /GL and (/O1 or /O2 or /Ox) options in Release x64 configuration.
That is OpenMP support and C++ optimization must be turned on. The resulting program should (should not) crash.
#include <omp.h>
#include <vector>
class EmptyClass
{
public:
EmptyClass() {}
};
class SuperEdge
{
public:
SuperEdge() {mp_points[0] = NULL; mp_points[1] = NULL;}
private:
const int* mp_points[2];
};
EmptyClass CreateEmptyClass(SuperEdge s)
{
return EmptyClass();
}
int main(int argc, wchar_t* argv[], wchar_t* envp[])
{
std::vector<int> v;
long count = 1000000;
SuperEdge edge;
#pragma omp parallel for
for(long i = 0; i < count; ++i)
{
EmptyClass p = CreateEmptyClass(edge);
#pragma omp critical
{
v.push_back(0);
}
}
return 0;
}
I think it is a bug. Looking at the ASM output with /O2 on the push_back call has been optimized away and there are just a couple of reserve calls and what looks like direct accesses instead. The reserve calls however don't appear to be in the critical section and you end up with Heap corruption. Doing a release x64 with /openmp /GL /Od you will see that there is a call to push_back in the asm, and it is between the _vcomp_enter_critsect calls, and doesn't crash. I'd report it to MS. (tested with VS 2010)