<list> throws unhandled exception when calling push_front()

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.