Hello Ricardo,
On Mon, Nov 27, 2017 at 04:33:45PM -0200, Ricardo Nabinger Sanchez wrote:
> Hello,
>
> While compile-testing 1.9-dev with Clang/LLVM analyzer, it found the
> following (possible) scenario:
>
> 1- in function cfg_cache_postparser(), when entering the nested loop in
> line 914, cache_ptr is free()ed and redefined to cache (line 918):
>
> 914 list_for_each_entry(cache, &caches, list) {
> 915 if (!strcmp(cache->id, cache_ptr)) {
> 916 /* there can be only one filter
> per cache, so we free it there */
> 917 free(cache_ptr);
> 918 cache_ptr = cache;
> 919 break;
> 920 }
> 921 }
>
>
> 2- loop is interrupted on the break in line 919;
>
> 3- if the test in line 923 passes (testing cache_ptr with the pointer
> fcont->conf), ha_alert() function in line 924 will be called and attempt
> to print/dereference the (recently freed) content pointed by
> fconf->conf:
>
> 923 if (cache_ptr == fconf->conf) {
> 924 ha_alert("Proxy '%s': unable to find the
> cache '%s' referenced by the filter 'cache'.\n",
> 925 curproxy->id, (char
> *)fconf->conf);
> 926 err++;
> 927 }
It doesn't try to print the freed pointer, but the "cache" variable since
it's what it was last assigned to. In practice, what was released was the
new pointer attempting to create the new filter, and what it printed is
the one found to conflict with it, so there is no problem here.
Thanks anyway for your report!
Willy
