...) has several fields not initialised, an error is now reported for
each field. Previously, an error was reported only for the first wrong
field.
+ - new flag --show-mismatched-frees=no|yes [yes], to optionally disable
+ allocator/deallocator mismatch checking.
* Helgrind:
- Race condition error message with allocated blocks also show
</listitem>
</varlistentry>
+ <varlistentry id="opt.show-mismatched-frees"
+ xreflabel="--show-mismatched-frees">
+ <term>
+ <option><![CDATA[--show-mismatched-frees=<yes|no> [default: yes] ]]></option>
+ </term>
+ <listitem>
+ <para>When enabled, Memcheck checks that heap blocks are
+ deallocated using a function that matches the allocating
+ function. That is, it expects <varname>free</varname> to be
+ used to deallocate blocks allocated
+ by <varname>malloc</varname>, <varname>delete</varname> for
+ blocks allocated by <varname>new</varname>,
+ and <varname>delete[]</varname> for blocks allocated
+ by <varname>new[]</varname>. If a mismatch is detected, an
+ error is reported. This is in general important because in some
+ environments, freeing with a non-matching function can cause
+ crashes.</para>
+
+ <para>There is however a scenario where such mismatches cannot
+ be avoided. That is when the user provides implementations of
+ <varname>new</varname>/<varname>new[]</varname> that
+ call <varname>malloc</varname> and
+ of <varname>delete</varname>/<varname>delete[]</varname> that
+ call <varname>free</varname>, and these functions are
+ asymmetrically inlined. For example, imagine
+ that <varname>delete[]</varname> is inlined
+ but <varname>new[]</varname> is not. The result is that
+ Memcheck "sees" all <varname>delete[]</varname> calls as direct
+ calls to <varname>free</varname>, even when the program source
+ contains no mismatched calls.</para>
+
+ <para>This causes a lot of confusing and irrelevant error
+ reports. <varname>--show-mismatched-frees=no</varname> disables
+ these checks. It is not generally advisable to disable them,
+ though, because you may miss real errors as a result.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="opt.ignore-ranges" xreflabel="--ignore-ranges">
<term>
<option><![CDATA[--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS] ]]></option>
Int MC_(clo_free_fill) = -1;
KeepStacktraces MC_(clo_keep_stacktraces) = KS_alloc_then_free;
Int MC_(clo_mc_level) = 2;
+Bool MC_(clo_show_mismatched_frees) = True;
static const HChar * MC_(parse_leak_heuristics_tokens) =
"-,stdstring,length64,newarray,multipleinheritance";
else if VG_XACT_CLO(arg, "--keep-stacktraces=none",
MC_(clo_keep_stacktraces), KS_none) {}
+ else if VG_BOOL_CLO(arg, "--show-mismatched-frees",
+ MC_(clo_show_mismatched_frees)) {}
+
else
return VG_(replacement_malloc_process_cmd_line_option)(arg);
" --free-fill=<hexnumber> fill free'd areas with given value\n"
" --keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none\n"
" stack trace(s) to keep for malloc'd/free'd areas [alloc-then-free]\n"
+" --show-mismatched-frees=no|yes show frees that don't match the allocator? [yes]\n"
, plo_default
);
}
static
void record_freemismatch_error (ThreadId tid, MC_Chunk* mc)
{
+ /* Only show such an error if the user hasn't disabled doing so. */
+ if (!MC_(clo_show_mismatched_frees))
+ return;
+
/* MC_(record_freemismatch_error) reports errors for still
allocated blocks but we are in the middle of freeing it. To
report the error correctly, we re-insert the chunk (making it