Access violation using edge function and stored_ra_edge_iter

[Geoff Hammerle <geoff.hammerle@…>]

I declare an adjacency_list as follows:

struct    MYvecS { }; 
template <class ValueType>
struct container_gen<MYvecS, ValueType> 
{
    typedef std::vector < ValueType, MyAllocator< ValueType > > type;
};
template <> struct parallel_edge_traits<MYvecS> { typedef allow_parallel_edge_tag type; };
namespace detail
{
    // allow random access to NXvecS stored elements
    template <> struct is_random_access<MYvecS> { enum { value = true }; typedef mpl::true_ type; };
}

typedef boost::adjacency_list < MYvecS,
                                MYvecS,
                                boost::undirectedS,
                                MYVertexType,
                                MYEdgeType,
                                no_property,
                                MYvecS
                                > MyGraphType;

I begin populating the graph with vertices and edges. If I use the edge function, passing in two valid vertices that are in the graph, the call to StoredEdge(v) crashes.

Referencing lines 312 thru 314 of detail\adjacency_list.hpp, you'll see that when a single argument is passed to this method, the other two arguments assume default values. In this case edge_vec = 0 and during this method call, it dereferences edge_vec which is set to NULL, and hence the access violation.

[Jeremiah Willcock]

Does the implementation of edge_range that's there work with your allocator? If so, I'll change edge to match that implementation.

[Jeremiah Willcock]

(In [82052]) Trying to fix defaults for StoredEdge; refs #7801

[Geoff Hammerle <geoff.hammerle@…>]

I don't think I can use the edge_range because my container for the edges is not associative. I get the error:

container_traits.hpp(550): error C2664: 'boost::graph_detail::equal_range_dispatch' : cannot convert parameter 3 from 'boost::graph_detail::vector_tag' to 'boost::graph_detail::associative_container_tag'

[Jeremiah Willcock]

Does the version of edge currently in the trunk work for you?

[Geoff Hammerle <geoff.hammerle@…>]

Initial testing of the trunk version works for me just fine. I will do more extensive testing and report here either way success or failure.

[Jeremiah Willcock]

Is this working? Should I close the bug?