]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
drd: Fix a 4x slowdown for certain applications (#316181)
authorBart Van Assche <bvanassche@acm.org>
Sun, 10 Mar 2013 10:43:11 +0000 (10:43 +0000)
committerBart Van Assche <bvanassche@acm.org>
Sun, 10 Mar 2013 10:43:11 +0000 (10:43 +0000)
This commit reverts r12629 ("drd: Don't sporadically report false positives on
newly allocated memory. Fixes #297147").

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13315

drd/drd_main.c

index 114779554c66adc44fd67a9da303d8d59af58f37..92c0f7992aa11b2c85d845c63932e7c67bb95a5e 100644 (file)
@@ -325,21 +325,8 @@ void drd_start_using_mem(const Addr a1, const SizeT len,
                       a1, len, DRD_(running_thread_inside_pthread_create)()
                       ? " (inside pthread_create())" : "");
 
-#if 0
    if (!is_stack_mem && DRD_(g_free_is_write))
       DRD_(thread_stop_using_mem)(a1, a2);
-#else
-   /*
-    * Sometimes it happens that a client starts using a memory range that has
-    * been accessed before but for which drd_stop_using_mem() has not been
-    * called for the entire range. It is not yet clear whether this is an
-    * out-of-range access by the client, an issue in the Valgrind core or an
-    * issue in DRD. Avoid that this issue triggers false positive reports by
-    * always clearing accesses for newly allocated memory ranges. See also
-    * http://bugs.kde.org/show_bug.cgi?id=297147.
-    */
-   DRD_(thread_stop_using_mem)(a1, a2);
-#endif
 
    if (UNLIKELY(DRD_(any_address_is_traced)()))
    {