🔒 Locked

std::list 'Access Violation' error

Started by James_Burke Dec 14, 2005 at 7:18 AM 9 replies 1.4k views

Original Post

Dec 14, 2005 at 7:18 AM

Hi, First off, I've only just registered here (haven't had the time to do so). Currently, I do programming (and occasionaly some level design ;)) in my spare time. I've been using several engines, but have decided to write my own for learning purposes. It is using DirectX and I have been following a lot of tutorials. I've run into this simple, annoying problem however, and would appriciate any help! My problem is this, I am using a for loop to go through a list of textures. It looks like this:


for(std::list<STexture*>::iterator iterator = m_list.begin(); iterator != m_list.end(); iterator++)

Now, the problem occurs when the Standed Libary tries to return the iterator. It says that it has a 'Access Violation'. Now I know this is not my coding error (at least within this whole function). Does anyone have any idea on what on earth is going on? In a demo application which uses this, it's fine as well. The code compiles fine and runs fine until it gets to that point at which, it will simply come up with the good old windows error! I'm using VC++ .NET 2003 with DX 9.0c. Any help would be greatly appriciated! Thanks, James Burke

ZQJ

Dec 14, 2005 at 7:33 AM

If the error shows up when you call m_list.begin() I'd say chances are that the this pointer is invalid.

Bregma

1,022

Bregma

Dec 14, 2005 at 8:00 AM

(1) Use ++iterator instead of iterator++ since list iterators are non-trivial and constructing and discarding a temporary is a waste of time.

(2) the C++ standard library has been around for a long time and tested by millions of users. Chances are good that the problem is not in the standard library but in your code.

(3) You are using a collection of pointers and you are getting an access violation. An access violatiomn usually means you're trying to dereference either a null pointer or an invalid pointer (it points to a deleted object).

My suggestion, without seeing any of the your code, is that you've put a pointer to an object into your list and then deleted that object somewhere, and when you iterate over the pointer you're running into a pointer to the deleted object (invoking undefined behaviour).

We can't, of course, help you find that bad code unless you post it.

--smw

James_Burke

Author

James_Burke

Dec 14, 2005 at 8:20 AM

Quote:
Original post by Bregma
My suggestion, without seeing any of the your code, is that you've put a pointer to an object into your list and then deleted that object somewhere, and when you iterate over the pointer you're running into a pointer to the deleted object (invoking undefined behaviour).

We can't, of course, help you find that bad code unless you post it.

Thanks for the help, so far, unless the parameters aren't getting through, it shouldn't be an invalid pointer, though I will double check this. The code is for an engine and so, it's kind of complicated to post it ;)

Thanks again,
James

James_Burke

Author

James_Burke

Dec 15, 2005 at 2:00 AM

Here is the exact information with DX debugging:

First-chance exception at 0x1002d4c6 (onedian.dll) in game.exe: 0xC0000005: Access violation reading location 0x0000000c.Unhandled exception at 0x1002d4c6 (onedian.dll) in game.exe: 0xC0000005: Access violation reading location 0x0000000c.

onedian.dll is the engine dll (where this is taking place) and game.exe is the exe file which calls the commands to the dll.

iMalc

182

iMalc

Dec 15, 2005 at 2:49 AM

Well, I for one can spot a NULL pointer a mile off. You've perhaps got a NULL pointer in your list.
Either that, or you've tried to perform some illegal operations on the list in the past, such as using invalidated iterators.

One thing is for sure, something is accessing a member variable that is 12 bytes past the start of some structure, or an array item that is 12 bytes from the start of an array, and in either case, the pointer is NULL.

"It's not a bug in my code" or something like that, sounds like famous last words to me.

James_Burke

Author

James_Burke

Dec 15, 2005 at 2:58 AM

Quote:
Original post by iMalc
"It's not a bug in my code" or something like that, sounds like famous last words to me.

In theory, it shouldn't be my code as it is directly from a DX book/tutorial and is the same as the example which runs fine. I've even copied/pasted the code but it must be somewhere else.
Thanks for the help,
James

RDragon1

206

RDragon1

Dec 15, 2005 at 4:18 AM

It looks like the 'this' pointer is null, and the access to m_list is probably what's causing the error. How did you get to the function that has this loop in it? Is it a member function of some object? If so, check to see that when you called the member function, the object you called it on is valid. Use the debugger and see what it says. Step back through the callstack and find out where things got mucked up.

Also, how did you get to assuming the problem was on that line you posted?

James_Burke

Author

James_Burke

Dec 15, 2005 at 7:10 AM

It's fixed!
Now ya'll ready to laugh ;) (believe me, it's funny).
So, I went back through the code as it wasn't making any sense except that the pointer wasn't being created. Now this part of the tutorial was focussing on the texture manager - so I started looking at the render objects and guess what!? There was no call to create the texture manager! This thing has been bugging me for nearly a week and all I had to do was add 2 lines:

if(!m_pTexManager)
m_pTexManager = new OTextureManager(m_pDevice);

Looks like I've learnt the hard way - always remember to call what you create :P
Again, thanks to all of you for ya help and I do hope you get a good laugh out of it (I certainly have ;))

Thanks again,
James

me22

Dec 15, 2005 at 7:21 AM

Note that this whole thing would have been avoided if you had just used a boost::ptr_list instead of the std::list.

ptr_list takes care of cloning when you copy, prevents you from having multipule copies of the same pointer in the list, deletes things when you erase them, removes the need for the extra implementation-detail dereference during traversal, and doesn't allow null pointers ( unless told otherwise ).

iMalc

182

iMalc

Dec 15, 2005 at 12:21 PM

Quote:
Original post by James_Burke
Quote:
Original post by iMalc
"It's not a bug in my code" or something like that, sounds like famous last words to me.

In theory, it shouldn't be my code as it is directly from a DX book/tutorial and is the same as the example which runs fine. I've even copied/pasted the code but it must be somewhere else.
Thanks for the help,
James

Sorry, I guess I'm just feeling a little more cynical than usual. It's just that a large number of bugs that are hard to track down are because we assume that it's not in some particular bit of code because we've been over it hundreds of times, yet someone else can come along and see the code for the first time and go "that doesn't look right", and you finally see it.
it would be nice being a code sample guaranteed it was bug free, but I've seen plenty of buggy code samples also.

You live, you learn. Well done!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.