-edit2- I was going down the wrong path. I solved it by correcting one typo and adding one line to fix an oversight that allowed me to write 4 bytes to many over an array.
-edit- maybe i am running through a wrong path. Maybe VS is showing me incorrect data but still runs the code properly (after all my code does show the correct name). But i have no idea where else my heap corruption could come from.
I havent notice any problems or incorrect data. But i have notice random crashes and suggestions that its caused by corrupting the heap.
I looked into something and this is what i notice. I have a class at address 0x00216e98. In my watch i can see the data correctly and below you can see the name ptr is 21bc00. I return the ptr as a base class (lets call it Base) which is inserted into a deque. As you can see in the deque (ls) it has one element and the first element is the correct pointer (i thought it may adjust but i guess not. But maybe it is but.....).
However the members it holds is COMPLETELY INCORRECT cdcdcd00 does not look like a valid name ptr to me and does not match to the ptr below. Also when my code is ran i somehow get the correct name and such so i dont know whats going on/wrong. It could be dynamic_cast magic but anyways if i am still grabbing the correct data i dont know how i am corrupting the heap (in both gcc and msvc).
I'll note i have diamond inheritance to the 'Base' class however like i said i am still pulling the correct data and i am not using virtual with base.
If you are using linux you might be able to use Valgrind. This is an exellent tool for finding heap related issues.
In debug mode cdcdcdcd is deleted uninitialized memory that the debug heap is marking for you.
If you see that, you are using a pointer to a deleted structure. memory that was allocated but never given a value.
Related
I got a program which uses a lot for memory for computations. Not too much, I guess. All bif arrays are stored at heap, of cause. MS VS 10 is my IDE. Task manager in Windows says it takes 1548 Kb. I am still writing it, and at some point I added
bool* mask= new bool [numberOfUnknowns];
and numberOfUnknowns is about 1600. It is in the public method of one of the classes (not sure if it matters). And I get
Unhandled exception at 0x777615de in ProgrammName.exe: 0xC0000005:
Access violation writing location 0x006a2000.
at this line. And it works with hard-coded
new bool [10];
and fails with
new bool [1600];
So, am I reaching possible memory size? Or should I check something else? I don't believe that I can't get more memory because putting
double* a = new double [100000];
in the main just for check makes memory size greater but the run-time error is on the same position.
Thanks in advance.
Addition 1:
I put the call of method that contains this line before all other calls and it worked. So, I guess, it's memory issue because of some memory allocated/freed during the work of other methods of my class. So, how is it possible? Should I post some more code or there is a common solution/description for such cases?
Addition 2: And for std::vector - need to find out what's wrong now, don't want to leave this problem without understanding.
Thanks for style correction of the post!
Use a std::vector. Your error is basically accessing memory you no longer own- either because you already freed it or past the end or something like that. You need to use a class-based solution to prevent this problem.
I have some code I wrote a few years ago. It has been working fine, but after a recent rebuild with some new, unrelated code elsewhere, it is no longer working. This is the code:
//myobject.h
...
inline CMapStringToOb* GetMap(void) {return (m_lpcMap);};
...
The above is accessed from the main app like so:
//otherclass.cpp
...
CMapStringToOb* lpcMap = static_cast<CMyObject*>(m_lpcBaseClass)->GetMap();
...
Like I said, this WAS working for a long time, but it's just decided to start failing as of our most recent build. I have debugged into this, and I am able to see that, in the code where the pointer is set, it is correctly setting the memory address to an actual value. I have even been able to step into the set function, write down the memory address, then move to this function, let it get 0xfdfdfdfd, and then manually get the memory address in the debugger. This causes the code to work. Now, from what I've read, 0xfdfdfdfd means guarding bytes or "no man's land", but I don't really understand what the implications of that are. Supposedly it also means an off by one error, but I don't understand how that could happen, if the code was working before.
I'm assuming from the Hungarian notation that you're using Visual Studio. Since you do know the address that holds the map pointer, start your program in the debugger and set a data breakpoint when that map pointer changes (the memory holding the map pointer, not the map pointed to). Then you'll find out exactly when it's getting overwritten.
0xfdfdfdfd typically implies that you have accessed memory that you weren't supposed to.
There is a good chance the memory was allocated and subsequently freed. So you're using freed memory.
static_cast can modify a pointer and you have an explicit cast to CMyObject and an implicit cast to CMapStringToOb. Check the validity of the pointer directly returned from GetMap().
Scenarios where "magic" happens almost always come back to memory corruption. I suspect that somewhere else in your code you've modified memory incorrectly, and it's resulting in this peculiar behavior. Try testing some different ways of entering this part of the code. Is the behavior consistent?
This could also be caused by an incorrectly built binary. Try cleaning and rebuilding your project.
We have been debugging a strange case for some days now, and have somewhat isolated the bug, but it still doesn't make any sense. Perhaps anyone here can give me a clue about what is going on.
The problem is an access violation that occur in a part of the code.
Basically we have something like this:
void aclass::somefunc() {
try {
erroneous_member_function(*someptr);
}
catch (AnException) {
}
}
void aclass::erroneous_member_function(const SomeObject& ref) {
// { //<--scope here error goes away
LargeObject obj = Singleton()->Object.someLargeObj; //<-remove this error goes away
//DummyDestruct dummy1//<-- this is not destroyed before the unreachable
throw AnException();
// } //<--end scope here error goes away
UnreachableClass unreachable; //<- remove this, and the error goes away
DummyDestruct dummy2; //<- destructor of this object is called!
}
While in the debugger it actually looks like it is destructing the UnreachableClass, and when I insert the DummyDestruct object this does not get destroyed before the strange destructor are called. So it is not seem like the destruction of the LargeObject is going awry.
All this is in the middle of production code, and it is very hard to isolate it to a small example.
My question is, does anyone have a clue about what is causing this, and what is happening? I have a quite full featured debugger available (Embarcadero RAD studio), but now I am not sure what to do with it.
Can anyone give me some advise on how to proceed?
Update:
I placed a DummyDestruct object beneath the throw clause, and placed a breakpoint in the destructor. The destructor for this object is entered (and its only us is in this piece of code).
With the information you have provided, and if everything is as you state, the only possible answer is a bug in the compiler/optimizer. Just add the extra scope with a comment (This is, again, if everything is exactly as you have stated).
Stuff like this sometimes happens due to writing through uninitialized pointers, out of bounds array access, etc. The point at which the error is caused may be quite removed from the place where it manifests. However, based on the symptoms you describe it seems to be localized in this function. Could the copy constructor of LargeObject be misbehaving? Is ref being used? Perhaps somePtr isn't pointing to a valid SomeObject. Is Singleton() returning a pointer to a valid object?
Compiler error is also a possibility, especially with aggressive optimization turned on. I would try to recreate the bug with no optimizations.
Time to practice my telepathic debugging skills:
My best guess is your application has a stack corruption bug. This can write junk over the call stack, which means the debugger is incorrectly reporting the function when you break, and it's not really in the destructor. Either that or you are incorrectly interpreting the debugger's information and the object really is being destructed correctly, but you don't know why!
If stack corruption is the case you're going to have a really tough time working out what the root cause is. This is why it's important to implement tonnes of diagnostics (eg. asserts) throughout your program so you can catch the stack corruption when it happens, rather than getting stuck on its weird side effects.
This might be a real long shot but I'm going to put it out there anyway...
You say you use borland - what version? And you say you see the error in a string - STL? Do you include winsock2 at all in your project?
The reason I ask is that I had a problem when using borland 6 (2002) and winsock - the header seemed to mess up the structure packing and meant different translation units had a different idea of the memory layout of std::string, depending on what headers were included by the translation unit, with predictably disastrous results.
Here's another wild guess, since you mentioned strings. I know of at least one implementation where (STL) string copying is done in a lazy manner (i.e., no actual copying of the string contents takes place until a change is made; the "copying" is done by simply having the target string object point to the same buffer as the source). In that particular implementation (GNU) there is a bug whereby excessive copying causes the reference counter (how many objects are using the same actual string memory after supposedly copying it) to roll over to 0, resulting in all sorts of mischief. I haven't encountered this bug myself, but have been told about it by someone who has. (I say this because one would think that the ref counter would be a 32 bit number and the chances of that ever rolling over are pretty slim, to say the least, so I may not be describing the problem properly.)
I'm working on a GUI in SDL. I've created a slave/master class that contains a std::list of pointers to it's own slaves to create a heirarchy in the GUI (window containing buttons. Button a label and so on). It worked fine for a good while, until I edited a completely different class that doesn't effect the slave/master class directly. The call to the list.push_front() in the old slave/master class now throws the following error when debugging in VS C++ 2008 express and I can't find what's causing it.
"Unhandled exception at 0x00b6decd in
workbench.exe: 0xC0000005: Access
violation reading location
0x00000004."
*workbench.exe is my project.
The exception is raised in the _Insert method in the list code on row 718:
_Nodeptr _Newnode = _Buynode(_Pnode, _Prevnode(_Pnode), _Val);
The list is created in the master/slave class' definition and the slave/master class is created on the heap to be inserted in another master's slave list. The list that crashes is empty when push_front() is called but it is second in line in the heirarchy, so it worked once. As I said, it worked fine before and the slave/master class hasn't been altered to cause the error.
The new class does use lists aswell. Can the use of several lists cause clashes? May I have accidentally screwed up the heap?
Any help and tips to what I could look for is appreciated.
P.S The code is rather large now so I would guess it's better to not include it. Especially since I'm not exactly sure just what causes the error. Sorry if it's a bit scarce
Update: I've replaced the push_front() with creating an iterator and using insert(). The result was an iterator pointing to "baadf00d" after assigning the list.begin(). baadf00d is some error/NULL pointer that VS uses to objects that haven't been assigned anything, as far as I can tell. I guess it's another sign that the list is corrupt?
Usually errors like this with addresses like 0x00000004 indicate dereferencing a NULL pointer, e.g.
struct point {
int x;
int y;
};
struct point *pt = NULL;
printf("%d\n", pt->y);
can create an error like that.
Doesn't smell like heap corruption to me, usually those errors tend to be subtler, I bet this is a case of a NULL pointer. I'd go up the call stack and hunt for null pointers, could be a member of the the object you're pushing on to the fron of the list or that object itself. If you do think this is a heap corruption issue, you can use gflags, which is free, to enable page heap and the like which will let you detect heap corruption earlier, hopefully as it happens, rather than by the side effects it causes later.
Probably, you have caused some kind of buffer overrun or other memory corruption in your original code which did not manifest until now. There is no risk of conflict between different list instances, and as you say, the new code does not interact with the old code. Therefore barring magic, you have coded a bug.
Given the lack of code, the best I can do is give you some scenarios I can think of:
The most obvious, and hardest to find, is a memory corruption. The list has been walked on, so adding to the item means the list manipulates crap memory.
You can test this by moving variables around in their declaration, and by changing the order of assignment. If this makes the error go away or move, you are looking at a memory problem. You could also try changing the list to a vector, and see what that does.
A second possibility is that you have a list of pointers/references and the items are being deallocated before/after being put on the stack. This can easily happen if you put the address of a stack object into a list allocated elsewhere. You say you created the object on the heap, so I guess it isn't this.
My guess, based on the seeing the combination of _Prevnode and push_front is that the list was corrupted earlier, possibly by misusing an iterator. Another way to corrupt a list is removing an element from an empty list. Make sure you have iterator debugging turned on in VS2008. It will catch many problems a lot earlier.
Finally after looking through every nook and cranny I've found the bug! It was completely unexpected and I feel a bit embarrassed about it.
I had recently re-arranged the files. Prior to that I had generic classes in one folder and my user interface files in a subfolder. I copied the GUI files to the main folder and I thought I linked everything up correctly, but obviously I missed one line and it never occurred to me when it started acting up. My library compiled since that was linked fine, but my testing program wasn't... it simply looked at the old header files! Worked fine to begin with ofcourse since the headers were the same, but then I edited one and the class declared in it started acting funny as mentioned, obviously, since it couldn't recognize the damn thing anymore. It looked like corrupted memory, so that's what I looked for.
Lesson learned: Don't keep two versions close to each other or at all.
I have a C++ program on Linux that crashes after some time with the message:
*** glibc detected *** free(): invalid pointer: 0x41e0ce94 ***
Inside the program I make extensive use of containers. They have to store objects of a simple class.
EDIT 2009-4-17:
In the meantime it seems clear that the error has nothing to do with the simple class. The error still occurs if I change the containers to hold other datatypes. The problem must be somewhere else in my code, I'm trying to figure it out at the moment...
Consider using a std::string to hold the string value instead of a raw char pointer. Then you won't have to worry about managing the string data in your assignment, copy, and destruction methods. Most likely your problem lies there.
Edit: There's no issue with the newer class you posted, and no problem with the first version if you're only using the char * to point to string constants. The problem lies elsewhere in the program or with the way you're using the class. You'll have to spend more time digging in the debugger and/or valgrind to track down the problem. I would figure out what is pointed to at the specified address and try determine why it's being freed twice.
At a guess, there is something wrong in your copy ctor, assignment op or destructor - you need to show the code for those.
Edit: Just noticed you don't have an assignment operator - assuming your copy constructor & destructor are OK, you need an assignment operator too, as the std:; containers will use it.
I have been fighting with a C/C++ application we are developing, and the first ideas that come to my mind are
A pointer has been modified and its pointing to an invalid possition (ptr++;) or something like that.
You have freed the object, but the pointer still holds the direction.
A tool like Valgrind may help you to detect possible errors in the code. To install:
sudo apt-get install valgrind
And to use it:
valgrind --tool=memcheck --leak-check=full ...
It will report errors while the program is running, and it will give you also a report after the program ends. The only problem is what valgrind identifies as a possible problem may not be a real problem. But it is an starting point.
It's most certainly a bad string value. Using std::string maybe help in this regard if it is a dangling pointer issue. Also ensure all the string initializations work as expected.
If I understand the class correctly, you assume that whatever memory resides at m_cstring won't be deallocated for the lifetime of the class. Which in your case also means for the lifetime of the containers. Check your scopes.
Another problem you may be encountering is if your Destructor is deleting the cstring then using a default value in the constructor is a really bad idea as you will be trying to deallocate a statically allocated cstring.
It is possible in C++ to define a function that is supposed to return a string, but doesn't return anything and you wind up with a bad string (Typically the compiler will catch the 'Reached end of non-void function', but not always).
Ditto on using valgrind.
As an addendum after reading various comments, there's always the possibility that a memory error somewhere else in the program corrupted one of the strings.
EDIT 4-16
At this point I would verify the values of the object are well formed on construct/destruct. (try printing them?) If everything looks good, you may have to look elsewhere in your code for the error.
What is inside your destructor? Probably it does free of the cstring. And If it is the case then you share your cstring pointer over instances and each instance then frees the same pointer.