I have recently made some modifications to my program and am now getting a lot of bad_alloc and out_of_range exceptions. I'm also using the latest boost-trunk version as I can't use 1.55 (I'm using VC++12 with boost-serialization).
Since I can't go back to a previous version with the old boost I can't just go through everything step-by-step to find the problem.
I'm not used to receiving these exceptions so I don't really know how to go about finding the cause. Here is one of the lines which causes an error (the location of the exception changes):
// userDefinedFile.cpp:
//
// colonySequence is std::list<std::unique_ptr<UserDefClass>>
// allocated_cells is std::vector<std::unique_ptr<UserDefClass>>
colonySequence.emplace_front(
new Colony(allocated_cells.begin(), allocated_cells.end())
); // this causes the error
Output:
HEAP[EDIN.exe]: HEAP: Free Heap block 7068430 modified at 706849c
after it was freed EDIN.exe has triggered a breakpoint.
Further up the stack in <vector> I am seeing this:
template<class _Iter>
void _Construct(_Iter _First, _Iter _Last, forward_iterator_tag)
{ // initialize with [_First, _Last), forward iterators
if (_Buy(_STD distance(_First, _Last))) // ERROR HERE
{ // nonzero, fill it
_TRY_BEGIN
this->_Mylast = _Ucopy(_First, _Last, this->_Myfirst);
_CATCH_ALL
_Tidy();
_RERAISE;
_CATCH_END
}
}
The value returned by _STD distance(_First, _Last) is large (116697808) and appears to cause the error, but the size of allocated_cells is only 46, so I don't understand why this is happening.
This doesn't seem like a symptom of a memory leak to me. How would you go about getting to the cause of this? What sort of code would you expect to generate this kind of error?
Here is the Colony constructor:
//Construct a colony with a sequence of cells
template <typename CellSptrIt>
Colony::Colony(CellSptrIt const begin, CellSptrIt const end) :
sector(&(*begin)->Sector()),
cellSequence(begin,end),
bounds(Colony::Bounds(begin,end))
{}
CellSptrIt is an iterator to a container of CellSptr objects, which are themselves a typedef for std::shared_ptr<Cell>. Cell is a user defined object, although since the constructor is not involved in the error I suspect it's not relevant. Cell.Sector() returns a reference to an object which describes the region of the cell, and the sector(&(*begin)->Sector()) therefore simply copies the sector value from the cell to the colony (a cell and a colony must belong to the same sector).
I was getting bad_alloc while doing serialization once because I was forgetting to close the output stream before reading it back in.
Related
I know what the error means and I know why it's throwing the error. However I do not understand as to how to resolve it. I have already read the other answers here on StackOverflow, which mostly tell what the error means.
I basically loop through elements, let the elements do something and then at the very end (outside of the loop), at the bottom of my method I use:
void someMethod()
{
for (Wagon& wagon: wagons)
{
//some code
}
wagons.erase(std::remove_if(wagons.begin(), wagons.end(), [](const Wagon& wagon) { return !wagon.active; }), wagons.end());
}
The second iteration it throws exception: std::out_of_range at memory location.
Basically what I am trying to do is remove inactive wagons, so they do not get iterated through the second time it calls the method which loops through the wagons.
hi i'm trying to send a QList as a parameter to another class but for some reason i got a read access violation...
CompareTimeChannel.h
class CompareTimeChannel : public IDataChannel
public:
// #brief The method used to receive the list
void setData(const QList< QSharedPointer<core::ITrackSection> > & sections);
// #brief The list
QList< QSharedPointer<core::ITrackSection> > _sections;
};
CompareTimeChannel.cpp
// #brief Empty constructor
CompareTimeChannel::CompareTimeChannel()
{
}
void CompareTimeChannel::setData(const QList< QSharedPointer<core::ITrackSection> > & sections)
{
//_sections = *new QList< QSharedPointer<core::ITrackSection> > ();
_sections.clear();
_sections.append(sections);
}
Running this code will throw Exception at 0x31cc78d, code: 0xc0000005: read access violation at: 0x4, flags=0x0 on _sections.clear();
I tried to initialize the list before (the commented line _sections = *new QList<...>) but the exception is thrown the same.
An answer would be very appreciated...
EDIT
Ok it's fixed!
First, like #AndreasT said, i had to initialize the default QList constructor.
Then, according to #10WaRRioR01 's answer, the issue comes from CompareTimeChannel which wasn't initialized the first time the method was called. Fixed using :
CompareTimeChannel* chan = static_cast<CompareTimeChannel*>(channel);
Q_ASSERT(chan);
if (chan) {
chan->setData(sections);
}
else {
qDebug() << "Dynamic cast failure";
}
Thank you all, guys!
//_sections = *new QList< QSharedPointer<core::ITrackSection> > ();
You shouldn't ever do something like this. This creates a new instance of QList on the heap and it will never be deleted, so you have a memory leak
You should have done
_sections = QList< QSharedPointer<core::ITrackSection> > ();
instead, and it would be legal. But the most simple way is to use a copy assignment like this
_sections = sections
The problem you got is most likely related to the data you have in _sections. Maybe you are calling your methods on a null CompareTimeChannel object
You should initialize sections in the constructor.
The commented line is just horribly wrong.
new constructs the List on the heap, then you dereference that with *new and the assignment implicitly calls the copy constructor of the new list on the Heap and copies that into the instance. The thing on the heap is still aruond though, so you just created a memory leak.
// #brief Empty constructor
CompareTimeChannel::CompareTimeChannel()
:_sections() // initialization default constructor.
{
}
Edit regarding the comment:
The QList.clear() method calls the destructors of every element of the list. At least one of your shared pointers seems not to be initialized correctly. If you need more info, please paste the code that puts stuff into _sections.
Edit Regarding the exception:
As I said the problem is most likely with the shared pointers not being set to anything interesting. When the SP gets destroyed it calls the destructor of its content, which must exist, otherwise it throws a read access violation, which would explain the symptoms.
This what you showed should work. Your problem is in some other place.
This kind of problems might be caused by many different mistakes, like: bad static_cast or bad c-style cast, break in binary compatibility when you are using dynamic libraries, write outside of table, problems with compiler cache (this happens is quite often so cure for that is below).
First what I would try to do:
make clean
qmake
make
This fixes such problem quite often. if i doesn't help you have to find other problems in your code.
I'm having problems creating a tmx map from string input.
bool LevelManager::initLevel(int currentLevel)
{
const char* map;
try {
map = LevelManager::getLevel(currentLevel);
} catch (int) {
throw 1;
}
if(map != NULL){
CCLog("%s", map);
tileMap = CCTMXTiledMap::create(map);
tileMap->setAnchorPoint(ccp(0,0));
tileMap->setPosition(ccp(15,20));
this->addChild(tileMap, 5);
backgoundLayer = tileMap->layerNamed("Background");
} else {
throw 1;
}
return true;
}
Thats my code.
It is very unstable. Most of the times it crashes and sometimes it doesn't.
I'm loading my map from the string map. Wich is a const *char.
My map is named Level1.tmx and when i load the map like this: tileMap = CCTMXTiledMap::create("Level1.tmx"); it always works and never crashes.
And i know for a fact that the value of map is Level1.tmx because i log it in the line before the load.
When it crashes the log outputs this: (lldb)
and on the line tileMap->setAnchorPoint(ccp(0,0)); it says "Thread 1: EXC_BAD_ACCESS (code=2, adress=0x0)
Does anyone know why this happens and how to fix it?
Many thanks.
Ps: i'm using xcode, the latest cocos2d-x release and the iPhone simulator
Edit:
Using breakpoints i checked where things go bad while loading the tilemap.
on the line tileMap = CCTMXTiledMap::create(map);
my variable map is still fine
but on line tileMap->setAnchorPoint(ccp(0,0));
it is suddenly corrupted (most of the time)
It sounds like you're returning a char* string created on the stack, which means the memory may or may not be corrupted, depending on circumstances, moon phases, and what not.
So the question is: How is getLevel defined and what does it do (post the code)?
If you do something like this:
const char* LevelManager::getLevel(int level)
{
char* levelName = "default.tmx";
return levelName;
}
…then that's going to be the culprit. The levelName variable is created on the stack, no memory (on the heap) is allocated for it. The levelName variable and the memory it points to become invalid as soon as the method returns.
Hence when the method leaves this area of memory where levelName points to can be allocated by other parts of the program or other method's stack memory. Whatever is in that area of memory may still be the string, or it may be (partially) overridden by other bits and bytes.
PS: Your exception handling code is …. well it shows a lack of understanding what exception handling does, how to use it and especially when. I hope these are just remnants of trying to get to the bottom of the issue, otherwise get rid of it. I recommend reading a tutorial and introductions on C++ exception handling if you want to continue to use exceptions. Especially something like (map != NULL) should be an assertion, not an exception.
I fixed it.
const char* was to blame.
When returning my map as a char * it worked flawless.
const char *levelFileName = level.attribute("file").value();
char *levelChar = new char[strlen(levelFileName) + 1];
std:: strcpy (levelChar, levelFileName);
return levelChar;
Thats how i now return the map.
I have been struggling with a segmentation fault for months, now I'm here to ask for help.
The segmentation fault appears when I call the following function
void foo(..., std::map<MyClass*, double> & x) {
if ( !x.empty() ) x.clear();
...
}
Class A {
private:
map<MyClass*, double> _N;
public:
void f(...) {
foo(..., _N);
...
}
};
//in main routine, the function is called in a loop
A a;
while(...) {
a.f(...);
}
Using gdb, I tacked the error to the line calling the clear() function, it shows "double free or corruption" error, and the program aborts at calling c++/4.1.2/ext/new_allocator.h:94 delete(__P) which further calls free() from the gnu library /lib64/libc.so.6. But since the elements in the map are not allocated by new, why it still calls free() to clear it up. I would really appreciate your comments. Thank you.
Given that the map is owned by another object it suspiciously sounds that the map-owning object was already deleted when the clear was called.
Also note that names starting with underscore and a capital letter are reserved for the implementation - you aren't allowed to use them.
The code looks fine to me. At least with the limited context you have provided. Usually when I run into issues like this I will simply run the valgrind memcheck tool to find the place were the first "delete" happened. Once you know that, these issues can be pretty simple to solve.
I am new to C++. I am getting HEAP CORRUPTION ERROR. Any help will be highly appreciated. Below is my code
class CEntity
{
//some member variables
CEntity(string section1,string section2);
CEntity();
virtual ~CEntity();
//pure virtual function ..
virtual CEntity* create()const = 0;
};
I derive CLine from CEntity as below
class CLine:public CEntity
{
// Again some variables ...
// Constructor and destructor
CLine(string section1,string section2);
CLine();
~CLine();
CLine* Create() const;
}
// CLine Implementation
CLine::CLine(string section1,string section2) : CEntity(section1,section2){};
CLine::CLine();
CLine* CLine::create() const {return new CLine();}
I have another class CReader which uses CLine object and populates it in a multimap as below
class CReader
{
public:
CReader();
~CReader();
multimap<int,CEntity*>m_data_vs_entity;
};
//CReader Implementation
CReader::CReader()
{
m_data_vs_entity.clear();
};
CReader::~CReader()
{
multimap<int,CEntity*>::iterator iter;
for(iter = m_data_vs_entity.begin();iter!=m_data_vs_entity.end();iter++)
{
CEntity* current_entity = iter->second;
if(current_entity)
delete current_entity;
}
m_data_vs_entity.clear();
}
I am reading the data from a file and then populating the CLine Class.The map gets populated in a function of CReader class. Since CEntity has a virtual destructor, I hope the piece of code in CReader's destructor should work. In fact, it does work for small files but I get HEAP CORRUPTION ERROR while working with bigger files. If there is something fundamentally wrong, then, please help me find it, as I have been scratching my head for quit some time now.
Thanks in advance and awaiting reply,
Regards,
Atul
Continued from Y'day :
Further studying this in detail I now have realized that Heap allocation error in my case is because I am allocating something, and then overwriting it with a higher size.
Below is the code where in my data gets populated in the constructor.
CEntity::CEntity(string section1,string section2)
{
size_t length;
char buffer[9];
//Entity Type Number
length = section1.copy(buffer,8,0);
buffer[length]='\0';
m_entity_type = atoi(buffer);
//Parameter Data Count
length = section1.copy(buffer,8,8);
buffer[length]='\0';
m_param_data_pointer = atoi(buffer);
//.... like wise ....
}
I am getting the values at a fixed interval of 8 chars and I am adding a '\0' so this, i guess will take care of any garbage value that I encounter.
About
Heap allocation error: after normal block (XXX) at XXX, CRT detected that application wrote to memory after end of Heap buffer. Mostly, Heap allocation errors occur somewhere else than where it crashes. I would appreciate if some one here would help me, how to make use of this normal block and the address.
Thanks,
Well, you're only showing half the problem.
Where's the code that creates the CLine objects and stores them in the CReader?
Also, what do you consider actually "owns" the CEntity objects? Generally, you should make the 'owner' responsible for creation as well as deletion...
I wrote earlier:
"You might like to consider storing
the CEntitys directly in the map,
rather than storing pointers.
Potentially less efficient, but also
much less scope for cockups."
As Neil points out, it's not CEntities that you will be storing, so that suggestion isn't going to help you much...
Finally, after two days of debugging, I was able to fix up the crash. It was due to me copying wrong number of characters from the string.
Lessons learnt :
1. When you encounter memory allocation errors, try to form a simple test case which has minimum entities to reproduce the problem.
2. A sure shot way is a line by line debugging. I agree,it test your patience, but then, there are no short cuts to success
3. And it gives you a chance to do a code review, further enhancing the quality of code that you produce in future
Thank you for all your help and formatting my code :)
Regards,
Atul