MB-20771: Remove unnecessary defragmenter_test operator overloads

The defragmenter & ep_unit tests have their own operator new/delete
overload, to improve interopability with Valgrind (so Valgrind saw
explicit calls our malloc / free).

However the global_new_replacement in platform does this anyway now, so
this code is no longer needed.

Change-Id: I49dbc9e14582d39b58b1db48a0c7772d4f3855c9
Reviewed-on: http://review.couchbase.org/67675
Well-Formed: buildbot <build@couchbase.com>
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Daniel Owen <owend@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>
Reviewed-by: Manu Dhundi <manu@couchbase.com>

diff --git a/tests/module_tests/defragmenter_test.cc b/tests/module_tests/defragmenter_test.cc
index ad981e7..5350481 100644 (file)
--- a/tests/module_tests/defragmenter_test.cc
+++ b/tests/module_tests/defragmenter_test.cc
@@ -24,36 +24,6 @@
 #include <locale>
 #include <platform/cb_malloc.h>
 
-#ifdef HAVE_JEMALLOC
-/* Global replacement of operators new and delete when using jemalloc.
- *
- * This isn't needed for functionality reasons (the code works
- * correctly without these), but to improve interoperability with
- * Valgrind. The issue encountered is that without these replacements,
- * the application will call the standard symbols in libstdc++, which
- * Valgrind intercepts, and replaces with it's own implementation
- * (which doesn't call 'our' je_malloc). As a consequence when the
- * memory tracking code (objectregistery.cc) later calls
- * je_malloc_usable_size() on the returned pointer from Valgrind's
- * operator new, we encounter invalid memory accesses as jemalloc is
- * trying to introspect a non-jemalloc allocation.
- *
- * By replacing operator new/delete in the executable program, we call
- * our own malloc/free (see alloc_hooks.c) which directly call
- * jemalloc.  Note that Valgrind reporting still works, as je_malloc
- * is able to detect which running in Valgrind and makes the
- * appropriate calls to Valgrind to inform it of allocations / frees.
- */
-void* operator new(std::size_t count ) {
-    return cb_malloc(count);
-}
-
-void operator delete(void* ptr ) noexcept
-{
-    cb_free(ptr);
-}
-#endif // HAVE_JEMALLOC
-
 
 static time_t start_time;
 

diff --git a/tests/module_tests/ep_unit_tests_main.cc b/tests/module_tests/ep_unit_tests_main.cc
index c375743..8055816 100644 (file)
--- a/tests/module_tests/ep_unit_tests_main.cc
+++ b/tests/module_tests/ep_unit_tests_main.cc
@@ -32,35 +32,6 @@
 /* static storage for environment variable set by putenv(). */
 static char allow_no_stats_env[] = "ALLOW_NO_STATS_UPDATE=yeah";
 
-#ifdef HAVE_JEMALLOC
-/* Global replacement of operators new and delete when using jemalloc.
- *
- * This isn't needed for functionality reasons (the code works
- * correctly without these), but to improve interoperability with
- * Valgrind. The issue encountered is that without these replacements,
- * the application will call the standard symbols in libstdc++, which
- * Valgrind intercepts, and replaces with it's own implementation
- * (which doesn't call 'our' je_malloc). As a consequence when the
- * memory tracking code (objectregistery.cc) later calls
- * je_malloc_usable_size() on the returned pointer from Valgrind's
- * operator new, we encounter invalid memory accesses as jemalloc is
- * trying to introspect a non-jemalloc allocation.
- *
- * By replacing operator new/delete in the executable program, we call
- * our own malloc/free (see alloc_hooks.c) which directly call
- * jemalloc.  Note that Valgrind reporting still works, as je_malloc
- * is able to detect which running in Valgrind and makes the
- * appropriate calls to Valgrind to inform it of allocations / frees.
- */
-void* operator new(std::size_t count ) {
-    return malloc(count);
-}
-
-void operator delete(void* ptr ) noexcept
-{
-    free(ptr);
-}
-#endif // HAVE_JEMALLOC
 
 int main(int argc, char **argv) {
     bool log_to_stderr = false;