Good catch, I'll analyze it further for the v2.9 release cycle!

Would be awesome to set up Travis-CI with automatic static code analysis with Coverity. That way we could get a better overview of memory handling issues like this. Must talk to @martinh about this later, maybe he can spare a few clock cycles of his time to do some clicking in those tools for us :)

I am also encountering an issue with freeing memory in the searchpath test. It causes infinite recursion in cfg_free_searchpath, making the stack overflow in MSYS2. Here is a trace I made with printf calls showing the problem; you can see that one searchpath (0000000000396f50) gets freed twice.

hello before cfg_init
hello before cfg_add_searchpath
hello before cfg_parse
Hello inside cfg_free_value(000000000039b200)
Hello inside cfg_free_value(000000000023f9c0)
Hello inside cfg_free_value(0000000001e241b0)
Hello inside cfg_free_value(000000000023f8c0)
Hello inside cfg_free_value(0000000001e243c0)
Hello before cfg_free
Hello inside cfg_free(00000000003962d0)
Hello inside cfg_free_value(0000000000396340)
Hello inside cfg_free_value(00000000003963c0)
Hello inside cfg_free(000000000039b110)
Hello inside cfg_free_value(000000000039b180)
Hello inside cfg_free_value(000000000039b200)
Hello inside cfg_free_opt_array 000000000039b180
hello inside cfg_free_searchpath 0000000000396f50
hello at the end of cfg_free 000000000039b160 000000000039b0b0 000000000039b350
Hello inside cfg_free(0000000001e240e0)
Hello inside cfg_free_value(0000000001e24130)
Hello inside cfg_free_value(0000000001e241b0)
Hello inside cfg_free_opt_array 0000000001e24130
hello inside cfg_free_searchpath 0000000000396f50
WHOA!  Circular linked list found in searchpath

The tests pass in Linux. Running the tests under Linux with Valgrind shows that there might be some leaks, but I'm not quite sure how to interpret the repetitive output from Valgrind.

Just to be clear, everything I am talking about here applies to my slightly-modified version of the current martinh/libconfuse master branch. I have not tried the patch from @peda-r yet.

I haven't looked carefully at the code, but this pull request from @peda-r does make searchpath.exe pass under Windows, so 👍 . It does not have a noticeable effect on the Valgrind output in Linux.

I switched back to the martinh version of libconfuse (e5b5082), and I can see that libconfuse is definitely confused about freeing searchpaths, even in Linux.

I added a printf statement to cfg_free_searchpath like this:

static void cfg_free_searchpath(cfg_searchpath_t* p)
{
    if (p)
    {
        printf("Freeing searchpath %p\n", p);
        cfg_free_searchpath(p->next);
        free(p);
    }
}

When I run ./searchpath in Arch Linux 64-bit (GCC 5.2.0), I get:

Freeing searchpath 0xd22470
Freeing searchpath 0xd22420
Freeing searchpath 0xd22300
Freeing searchpath 0xd22470
Freeing searchpath 0xd22420
Freeing searchpath 0xd22300
Freeing searchpath 0xd22470
Freeing searchpath 0xd22420
Freeing searchpath 0xd22300
Freeing searchpath 0xd22470
Freeing searchpath 0xd22420
Freeing searchpath 0xd22300

The test passes somehow, but it's clear that the library is severely malfunctioning, and I would not recommend releasing it in this state.

Thank you for the analysis @DavidEGrayson, you just convinced me this PR needs to be merged for the v2.8 release 😃

Squashed the two commits into one and updated the commit message slightly.
Fixed in master commit 64a5cb3

Great, thanks!