Something went wrong on our end
-
William Roberts authored
rule_map_free() took as a parameter a boolean menu rule_map_switch that was used to determine if it should free the key pointer that is also in the table. On GLIBC variants, calls to hdestroy do not free the key pointer, on NON-GLIBC variants, it does. The original patch was meant to correct this, however, it always passes "destroy" as the rule_map_switch. On GLIBC variants this is fine, however on NON-GLIBC variants, that free was compiled out, and the free() was handled by hdestroy. In cases of failure where the rule_map was not in the htable, those key's were not properly free'd. Change-Id: Ifdf616e09862bca642a4d31bf0cb266168170e50 Signed-off-by:
William Roberts <william.c.roberts@intel.com>
William Roberts authoredrule_map_free() took as a parameter a boolean menu rule_map_switch that was used to determine if it should free the key pointer that is also in the table. On GLIBC variants, calls to hdestroy do not free the key pointer, on NON-GLIBC variants, it does. The original patch was meant to correct this, however, it always passes "destroy" as the rule_map_switch. On GLIBC variants this is fine, however on NON-GLIBC variants, that free was compiled out, and the free() was handled by hdestroy. In cases of failure where the rule_map was not in the htable, those key's were not properly free'd. Change-Id: Ifdf616e09862bca642a4d31bf0cb266168170e50 Signed-off-by:
William Roberts <william.c.roberts@intel.com>