Possible memory leak in binheap.c

[mattgallivan]

I'm currently unable to share the code that triggers this memory leak but I have traced it using valgrind through the following calls:

==77605== 4,811,032 (4,066,576 direct, 744,456 indirect) bytes in 187,682 blocks are definitely lost in loss record 10 of 10
==77605==    at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==77605==    by 0x10E6F3: binomial_tree_merge (binheap.c:399)
==77605==    by 0x10E8B3: binheap_insert (binheap.c:427)
==77605==    by 0x10D12E: pqueue_insert (pqueue.c:78)

This is one of ten leaks that valgrind detects over a relatively short span of inserting items into a priority queue. It seems like the realloc from binomial_tree_merge is not beeing freed.

I am doing something funky in that I am passing size_t values and casting them as void* types in my priority queue but this seems to work. I don't know if there is an underlying assumption anywhere that the values must be pointers (for example, this approach doesn't work with hastable.c because the hash function accesses the pointers; I don't believe pqueue or binheap do this, though).

[xant]

Thanks for reporting! This has been now fixed in ac6cda