Memory leak in maximal_weighted_matching

[Soldann]

Hello,

I am getting a memory leak in Boost Version 1.83.0 when running maximum_weighted_matching on a small fully connected graph.

Using the following code:

#include <iostream>
#include <vector>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/maximum_weighted_matching.hpp>


int main() {
    typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::no_property, boost::property<boost::edge_weight_t, double>> SimpleMatchingGraph;

    SimpleMatchingGraph graph(4);

    std::vector<boost::graph_traits<SimpleMatchingGraph>::vertex_descriptor> mate(boost::num_vertices(graph));

    boost::add_edge(0, 1, {4.0}, graph);
    boost::add_edge(0, 2, {1.0}, graph);
    boost::add_edge(0, 3, {2.0}, graph);
    boost::add_edge(1, 2, {10.0}, graph);
    boost::add_edge(1, 3, {11.0}, graph);
    boost::add_edge(2, 3, {8.0}, graph);

    boost::maximum_weighted_matching(graph, mate.data());
}

Gives the result:

$ g++ test.cpp    
$ valgrind ./a.out            
==1151985== Memcheck, a memory error detector
==1151985== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1151985== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1151985== Command: ./a.out
==1151985== 
==1151985== 
==1151985== HEAP SUMMARY:
==1151985==     in use at exit: 440 bytes in 5 blocks
==1151985==   total heap usage: 106 allocs, 101 frees, 79,505 bytes allocated
==1151985== 
==1151985== LEAK SUMMARY:
==1151985==    definitely lost: 96 bytes in 1 blocks
==1151985==    indirectly lost: 344 bytes in 4 blocks
==1151985==      possibly lost: 0 bytes in 0 blocks
==1151985==    still reachable: 0 bytes in 0 blocks
==1151985==         suppressed: 0 bytes in 0 blocks
==1151985== Rerun with --leak-check=full to see details of leaked memory
==1151985== 
==1151985== For lists of detected and suppressed errors, rerun with: -s
==1151985== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[jeremy-murphy]

I tested with the head of develop and saw no memory leaks, so I believe this was fixed recently.

Apologies, but master is a bit behind at the moment.