iterator not working

[xander333]

This is by far the weirdest bug I've ever encountered.
It seems like the for statement is broken (lol)!

    for(std::list<Bonus*>::const_iterator itr = bonuses.begin(); itr != bonuses.end(); itr++)
    {
        (*itr)->update();
    }

When I place a breakpoint inside it (exactly before the SIGSEGV segmentation fault occurs) I can see that the address of itr = 0x0. A NULL POINTER AAARGH

How is that possible?

[Athar]

I wouldn't always trust the debugger unconditionally (are you compiling with optimizations enabled?).
Does an assert(*itr) before the call get triggered?
What does update() do? Can it remove the element from the list?

[xander333]

Nope, it simply moves the sprite in the object.

And optimizations are disabled.

And yes the assert fails.

[Athar]

Then it looks like you actually have a null pointer in your list.

[xander333]

That's impossible as I never add anything to it :s

[Athar]

There are other ways it can happen, like writing out of array bounds or writing to already deleted objects somewhere else in your code.

[xander333]

I have no arrays in my code.
And objects are not deleted (I Ctrl+R 'ed the project and temporarily commented out all the deletes)

EDIT: now I'm getting segmentation faults ON the assert :s

[Athar]

Well, "array" is representative for all sorts of containers.
Dereferencing other invalid pointers or iterators can do it too. What happens if you enable debug iterators? Or are they already enabled?

EDIT: now I'm getting segmentation faults ON the assert :s

Well, that's getting a bit strange. What happens when you print &itr and *itr every iteration?
You might want to look at the generated assembler code and the exact instruction that triggers the segmentation fault too.

[xander333]

How do I enable debug itrs?
And I'll print em out.

[Athar]

Debug iterators are enabled by the global macro _GLIBCXX_DEBUG in GCC and with _SECURE_SCL=1 in VC++.

[xander333]

Ok I tried printing them, but it doesn't output anything.
std::cout seems to have stopped working, for example my std::cout statement in the contructor of my class doesn't output either :s

what the hell :s

[Athar]

Hm, are you flushing the output stream (endl or flush)?

[xander333]

I get this error (via console)

warning:gdb:Failed to set controlling terminal: operation not permitted.

I'm now also getting segmentation faults on std::cout (only when i try printing itr)
It seems my iterator crashes everything it touches :p

[Athar]

Sounds fun. The warning should be safe to ignore.
Are you on a Linux system or Mac OS, so you can run your program with valgrind?

[xander333]

I'm on Linux (Xubuntu Oneiric)
I installed valgrind and I'll attempt running it :)

[xander333]

My program does not seem to work using valgrind...
I get a blank window :s

[Athar]

Perhaps you started it from the wrong working directory (if you use relative paths for loading resources)?
Does valgrind already print any warnings until that point?

[xander333]

I got it working!

relevant output bits:

Invalid read of size 8
==5012==    at 0x4135AB: Level::update(int) (Level.cpp:145)
==5012==    by 0x40C8AE: GameState::update() (GameState.cpp:42)
==5012==    by 0x5AA58A8: sfge::StateManager::update() (StateManager.cpp:60)
==5012==    by 0x40BC5B: Game::run() (Game.cpp:29)
==5012==    by 0x417D07: main (main.cpp:10)
==5012==  Address 0x7803f800010 is not stack'd, malloc'd or (recently) free'd
==5012== 
==5012== 
==5012== Process terminating with default action of signal 11 (SIGSEGV)
==5012==  Access not within mapped region at address 0x7803F800010
==5012==    at 0x4135AB: Level::update(int) (Level.cpp:145)
==5012==    by 0x40C8AE: GameState::update() (GameState.cpp:42)
==5012==    by 0x5AA58A8: sfge::StateManager::update() (StateManager.cpp:60)
==5012==    by 0x40BC5B: Game::run() (Game.cpp:29)
==5012==    by 0x417D07: main (main.cpp:10)
==5012==  If you believe this happened as a result of a stack
==5012==  overflow in your program's main thread (unlikely but
==5012==  possible), you can try to increase the size of the
==5012==  main thread stack using the --main-stacksize= flag.
==5012==  The main thread stack size used in this run was 8388608.
uccesfully loaded in32 brick==5012== 

That's exactly where the segmentation fault occurs.
What does it add to what we know already?

[Athar]

It does show that Level::update() attempts to do something untoward in line 145.

[xander333]

That's the (*itr)->update() line :)