graph help

Started by
4 comments, last by antarctica 15 years, 10 months ago
Hi there, im trying to play around with the pathfinder example (chapter 5) from the "Game AI by example book" and ive run into some problems that i hope someone can help me with since, the books offical forums are defunct. compiles ok, but i get the error "List iterator not dereferenceable" in debug mode as it bails out, in release it says: Problem signature: Problem Event Name: BEX Application Name: Pathfinder.exe Application Version: 1.0.0.1 Application Timestamp: 485a7163 Fault Module Name: Pathfinder.exe Fault Module Version: 1.0.0.1 Fault Module Timestamp: 485a7163 Exception Offset: 000151a1 Exception Code: c000000d Exception Data: 00000000 OS Version: 6.0.6001.2.1.0.256.1 Locale ID: 2057 Additional Information 1: e908 Additional Information 2: 717bb35e13d7fd1c2024bd56c3d19b45 Additional Information 3: 3e8f Additional Information 4: d48b2921942e0a7acb0b5710db691a03 but ive been unable to find out what BEX means so far. as i have not modified the source code, im presuming its some sort of incompatability with newer versions of STL or other "standard" files with visual studio 2005 sp1 perhaps?, think the iterator is running off end of the vector? or something?, has anybody else run into this issue?
Advertisement
Have you tried running it in the debugger in debug mode and seeing where in the code the exception occurs?

-me
yeah ive been doing it for a while and ive gotas far as thinking its when ever there is something like:

for (const Edge* pE=ConstEdgeItr.begin();
!ConstEdgeItr.end();
pE=ConstEdgeItr.next())


as theres a few.
----------------------------

!ConstEdgeItr.end();
^^ i think its not liking this bit , which is a bool:

bool end()
{
return (curEdge == G.m_Edges[NodeIndex].end());
}

so somehow the iterator isnt doing what its supposed to?, im not really 100% when it comes to iterators (or templatised programming for that matter)

i shall keep digging, i just thought (hoped) this was an already known issue

edit- i should also add that the error message is from std::list
and the last few lines of the stack are:

> Pathfinder.exe!std::_Debug_message(const wchar_t * message=0x005201c8, const wchar_t * file=0x00520218, unsigned int line=213) Line 24 C++

Pathfinder.exe!std::list<GraphEdge,std::allocator<GraphEdge> >::_Const_iterator<1>::operator*() Line 213 + 0x14 bytes C++

Pathfinder.exe!SparseGraph<NavGraphNode<void *>,GraphEdge>::ConstEdgeIterator::next() Line 252 C++
hmm prob deffo seems to be with

return &(*curEdge);

when

curEdge == G.m_Edges[NodeIndex].end()

although it copes alright when its .begin()?

i am baffled!

edit - on a sneaky suspicion i tried it on vs 2003 and it works fine
looks like it must be something to do with 2005/ .net framework 2.0
implementation of std::list which is a little odd, has anyone else encountered an issue like this?

...i should have edited my first post, not added replys, sorry about that

[Edited by - antarctica on June 19, 2008 9:36:31 PM]
The way that Mat has dealt with his edge iterators is a bit messy (sorry Mat, but it is ;) ). The call to next() is incrementing the curEdge member variable for the EdgeIterator/ConstEdgeIterator classes beyond the end of the list, before the call to end() returns true (it is required to return a boolean value, so don't worry about that). Unfortunately, simply placing a test for end() within the next() method before incrementing doesn't work (tried that simple fix) as it then creates an infinite loop in the for-loop.

Personally, I would have dealt with iterating over edges differently. The for loop should loop over iterators and dereference them to obtain the edge, rather than hiding the iterators and returning edges directly.

Regards,

Timkin
yeah i can kind of see why he did it the way that he did, but i wish he didnt :P

as a temp fudge until i actually understand it all a bit better, ive changed return type from bool to EdgeType and NodeType, added reverse_iterators and used .rbegin() instead of .end() which seems to work for now.

think its just changes in how iterators are handled in std:list, or at least how undefined behaviours are handled by between different versions of ms compilier?

but for now i must sleep...

This topic is closed to new replies.

Advertisement