Everything compiles fine, but during run time, it crashes without any coredumps, exceptions or no logs clues about what is happening. After inserting debug lines, I found that it was around this section of code
if( MISC_TABLE_ID != tableID )
{
OrbSchemaStructure orbSchemaStruct;
orbSchemaStruct.tableName = tableView;
orbSchemaStruct.columnName = colName;
orbSchemaStruct.dataType = tsFact->convertDBDataTypeToEVDataType( toString( col.type() ) );
orbSchemaStruct.primaryKeyComponent = pkComponent;
schemaStructureDeque.push_back( orbSchemaStruct ); //crashes after this line
}
And it is happening on the last line of this block, where the push_back happens.
and the schemaStructureDeque happens to be an object of type DEQUE< OrbSchemaStructure >& schemaStructureDeque where DEQUE is a define for std::deque.
The OrbSchemaStructure is a struct defined in an idl as follows :
struct OrbSchemaStructure
{
string tableName;
string columnName;
unsigned long dataType;
boolean primaryKeyComponent;
};
Was there any change to the way deques are handled? Am I missing something?
Before writing this question off as too localized, please let me know if I am missing any info, or if I am not looking in the right place.
I am using omniORB 4.0.4 btw.
On compiling in the omniORB on AIX using the new AIX 11.1 C++ compiler, and linking it with the binary, it has stopped crashing.
Related
lately I have been faced with a strange problem that a simple source did not want to compile. I was looking for solutions (and cause) in many sites but without good effects (except bugs reports but I have not found there direct cause ).
Below I present simple code to reproduce that situation:
struct Foo {
Foo() : m_x( true ) {}
__property bool x = { read=m_x };
private:
bool m_x;
};
template<typename T>
struct TMyPointer {
T * m_ptr;
TMyPointer( T * ptr ) : m_ptr( ptr ) {}
~TMyPointer()
{
delete m_ptr;
}
T * operator->() const
{
return Get();
}
T * Get() const
{
if( m_ptr == NULL )
; // some error handling
return m_ptr;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
TMyPointer<Foo> bar( new Foo );
if( bar->x && 1 == 1 ) ; // Failed
if( 1 == 1 && bar->x ) ; // OK
if( !!bar->x && 1 == 1 ) ; // OK
if( bar->x == true && 1 == 1 ) ; // OK
if( (bar->x) && 1 == 1 ) ; // OK
return 0;
}
Compiler has failed to compile first condition inside main function. What stranger compilation of other equivalent conditions is finished successfully.
That's behavior I have only during release compilation. To reproduce I have used Embarcadero® C++Builder® XE5 Version 19.0.13476.4176
Error message: [bcc32 Fatal Error] File1.cpp(43): F1004 Internal
compiler error at 0x14470090 with base 0x14410000
Anybody knows what is the problematic in above example? Maybe usage templates with properties mechanism is the cause?
In my case is simple solution it seems to be problematic condition inside Get method. When I change
if( m_ptr == NULL )
to equivalent form
if( !m_ptr )
everything compile without errors.
I am writing about it here becouse I would like to share my insights - it can be helpfully for somebody.
recently I got similar ICE (once my source code grows in size) and your solution seemingly helped for a while but not really as after some minor changes in code ICE resurfaced again. Based on the behavior of mine problem:
IDE: BDS2006 Turbo C++ explorer (its version of BCB between BCB6 and RAD)
Huge win32 project (several MBytes of code involving USB,OpenGL,CAD/CAM)
Each part of code is tested for years and compilable separably problem occurs once they together and code grows too big
Project compiles fine at first run but after that any recompile fails
The temporary workaround was to close IDE, delete all obj,tds,exe,... files restart IDE and compile again.
I assumed compiler and or IDE leaks or overwrites some parts of itself corrupting its functionality. As the problem persist after IDE restart without deleting temp files I assumed it has something to do with debug info stored in them.
So I played with Project->Options->Debugging settings and turning off this:
Inline function expansion (-vi)
Helped (not even IDE restart or temp file removal was needed).
Don't have enough reputation to upvote or comment someone else's posts, but I have recently found the same solution as in #Spektre reply.
Disabling Inline function expansion fixed our multiple-year problems with completely unrelated internal compiler errors on random projects. We only experienced them on MSBUILD scripts in Release config.
I found this out by going over all the compiler options in Release config that were different from Debug config and changed them one-by-one to match Debug config through msbuild parameters for the entire solution/projectgroup. And eventually it started to build without any errors when I've disabled Inline function expansion option.
These problems happened and I confirmed the fix on C++ Builder XE5;
This kept on resurfacing at random for as long as I can remember (Borland C++ 2006 and later)
The older developers used to try and revert latest commits until it started compiling again... Which is a pain in the behind.
Anyone looking for solution to pass a parameter to an MSBUILD command (for all targets in the script) add this line to the msbuild.exe call:
msbuild.exe Targets.xml /p:BCC_InlineFunctionExpansion=false /t:Build
All,
I've written code to serialize our API's calls using boost serialization. The saving is being performed on linux and the loading on windows, so I went to a text_?archive to begin with. I am able to easily save and load the archive on linux, however when I switch to windows I get an access violation after I've created the text_iarchive while reading the first struct.
After stepping through the boost code with the debugger I've found the issue.
In "boost/archive/basic_text_iprimitive.hpp" I get the access violation on line 84:
template<class T>
void load(T & t)
{
if(is >> t)
return;
boost::serialization::throw_exception(
archive_exception(archive_exception::input_stream_error)
);
}
Specifically the crash is happening inside of is >> t. I've tried a few things to fix this, but with it being boost code I'd rather not have a solution reliant on modifying their code. The first fix was to add:
std::stringstream ss;
std::string str;
is >> str;
ss.str(str);
ss >> t;
if ( is )
return;
boost::serialization::throw_exception(
archive_exception(archive_exception::input_stream_error));
Unfortunately this worked and my program kept running. It is a horrible horrible hack, so I tried something else. The calling function looks like:
void load(version_type & t){
unsigned int v;
load(v);
t = version_type(v);
}
Fairly benign. I first tried to initialize the unsigned int to 0, but that did nothing. My co-worker then recommended changing the unsigned int to an int [albeit jokingly]. Sure enough it worked. Again this is a change in boost code so I'd rather not keep the fix there.
Unfortunately I am unable to reproduce this problem outside of code I can't share. I've been able to make a new Visual Studio project and load the file just fine, so I'm not sure what settings I may have changed that would cause such a problem.
Any help would be appreciated!
EDIT
I was able to fix this. I'm still unsure of the cause but the problem stemmed from the way in whichI was calling the serialization code.
What I had was:
int main()
{
struct s;
std::ifstream infile("output.txt");
std::ifstream types("types.txt");
boost::archive::text_iarchive ia(infile);
int type = 0;
types >> type;
switch( type )
{
case 1:
ia >> s;
}
return 0;
}
Putting the the entirety of "case 1" in its own scope [including declaring the struct] worked like a charm.
I'm using C++ in Visual Studio 2005 (large legacy project).
Have the following code snippet:
bool FOO::bar(const string& input_text)
{
string::const_iterator
ch = input_text.begin(),
last_ch = input_text.end();
for( ; ch!=last_ch; ++ch )
{
/////////////////////////////////////////////////////
const char a = *ch;
/////////////////////////////////////////////////////
}
return true;
}
When I run this code in debug mode it crashes on the const char a = *ch line and says:
Unhandled exception at 0x0000000140d08b20 in foobar.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
When I run this code in release mode, it runs just fine.
This code is called as follows:
CString full_filter;
full_filter.Format( "*%s*", filter_value );
foo.bar((LPCTSTR)full_filter));
I am a VS2005 C++ novice, so am looking up what these mean now, but put this in due to questions in comments section.
I have found a number of seemingly related C questions and answers about this. Based on those, I have tried defining various values for input_text, such as removing it from the parameters and just defining it as
string input_text("FOO");
or
string input_text = "FOO";
or
char[] tmp = "FOO"; string input_text = tmp;
All have failed.
I have also taken the above code snippet and put it into it's own brand spanking new VS2005 project, and it runs just fine.
So, there are some .... unique settings in the legacy VS2005 project that are causing problems. Any clue what those settings might possibly be, or how to smoke them out? I'm a rank VS2005 novice.
I have a c++ program that takes a map text file and outputs it to a graph data structure I have made. I am using QT as I needed cross-platform program and GUI as well as visual representation of the map. I have several maps in different sizes (8x8 to 4096x4096).
I am using unordered_map with a vector as key and vertex as value, I'm sending hash(1) and equal functions which I wrote to the unordered_map in creation.
Under QT I am debugging my program with QT 4.8.1 for desktop MinGW (QT SDK), the program works and debugs well until I try the largest map of 4096x4096, then the program gets stuck with the following error:
the inferior stopped because it received a signal from operating system
When debugging, the program halts at the hash function which used inside the unordered_map and not as part of the insertion state, but at a getter(2).
Under Netbeans IDE 7.2 and Cygwin4 all works fine (debug and run).
Some code info:
typedef std::vector<double> coordinate;
`typedef std::unordered_map<coordinate const*, Vertex<Element>*, container_hash, container_equal> vertexsContainer;`
`vertexsContainer *m_vertexes`
(1) hash function:
struct container_hash
{
size_t operator()(coordinate const *cord) const
{
size_t sum = 0;
std::ostringstream ss;
for ( auto it = cord->begin() ; it != cord->end() ; ++it )
{
ss << *it;
}
sum = std::hash<std::string>()(ss.str());
return sum;
}
};
(2) the getter:
template <class Element>
Vertex<Element> *Graph<Element>::getVertex(const coordinate &cord)
{
try
{
Vertex<Element> *v = m_vertexes->at(&cord);
return v;
}
catch (std::exception& e)
{
return NULL;
}
}
I was thinking maybe it was some memory issue at the beginning, so before I was thinking of trying Netbeans I checked it with QT on my friend pc with a 16GB RAM and got the same error.
Update:
I try to run this on visual studio 2012, I got a bad_alloc error which halt my program, when looking at task manager I saw the memory assigned to the program was going up to 2GB, could be it's because it's a 32bit program?
Update
I debugged my program under Netbeans with 32bit architecture and Cygwin4 and all worked fine, so maybe it is not a 32 bit problem, also the memory used with netbeans was 1.5GB, so how in MinGW and VS2012 it's going up to 2GB?
Question is in bold below :
This works fine:
void process_batch(
string_vector & v
)
{
training_entry te;
entry_vector sv;
assert(sv.size() == 0);
...
}
However, this causes the assert to fail :
void process_batch(
string_vector & v
)
{
entry_vector sv;
training_entry te;
assert(sv.size() == 0);
...
}
Now I know this issue isn't shrink wrapped, so I'll restrict my question to this: what conditions could cause such a problem ? Specifically: variable initialization getting damaged dependant on appearance order in the stack frame. There are no malloc's or free's in my code, and no unsafe functions like strcpy, memcpy etc... it's modern c++. Compilers used: gcc and clang.
For brevity here are the type's
struct line_string
{
boost::uint32_t line_no;
std::string line;
};
typedef std::vector<boost::uint32_t> line_vector;
typedef std::vector<line_vector> entry_vector;
typedef std::vector<line_string> string_vector;
struct training_body
{
boost::uint32_t url_id;
bool relevant;
};
struct training_entry
{
boost::uint32_t session_id;
boost::uint32_t region_id;
std::vector< training_body> urls;
};
p.s., I am in no way saying that there is a issue in the compiler, it's probably my code. But since I am templatizing some code I wrote a long time ago, the issue has me completely stumped, I don't know where to look to find the problem.
edit
followed nim's suggestion and went through the following loop
shrink wrap the code to what I have shown here, compile and test, no problem.
#if 0 #endif to shrink wrap the main program.
remove headers till it compiles in shrink wrapped form.
remove library links till compiles in shrink wrapped form.
Solution: removing link to protocol buffers gets rid of the problem
The C++ standard guarantees that the following assertion will succeed:
std::vector<anything> Default;
//in your case anything is line_vector and Default is sv
assert(Default.size() == 0);
So, either you're not telling the whole story or you have a broken STL implementation.
OR: You have undefined behavior in your code. The C++ standard gives no guarantees about the behavior of a program which has a construct leading to UB, even prior to reaching that construct.
The usual case for this when one of the created objects writes beyond
its end in the constructor. And the most frequent reason this happens
in code I've seen is that object files have been compiled with different
versions of the header; e.g. at some point in time, you added (or
removed) a data member of one of the classes, and didn't recompile all
of the files which use it.
What might cause the sort of problem you see is a user-defined type with a misbehaving constructor;
class BrokenType {
public:
int i;
BrokenType() { this[1].i = 9999; } // Bug!
};
void process_batch(
string_vector & v
)
{
training_entry te;
BrokenType b; // bug in BrokenType shows up as assert fail in std::vector
entry_vector sv;
assert(sv.size() < 100);
...
}
Do you have the right version of the Boost libaries suited for your platform? (64 bit/32 bit)? I'm asking since the entry_vector object seems to be have a couple of member variables of type boost::uint32_t. I'm not sure what could be the behaviour if your executable is built for one platform and the boost library loaded is of another platform.