[Mac] Remove potential for malloc in CrMallocErrorBreak().

base/process_util_mac.mm

Index: base/process_util_mac.mm
diff --git a/base/process_util_mac.mm b/base/process_util_mac.mm
index 1fa3dbbb4067145c4038a63ab3c25ab0c22be9db..786ff2124f8e36b59f0fea49554eccfe422984eb 100644
--- a/base/process_util_mac.mm
+++ b/base/process_util_mac.mm
@@ -35,6 +35,7 @@
 #include "base/logging.h"
 #include "base/mac/mac_util.h"
 #include "base/mac/scoped_mach_port.h"
+#include "base/safe_strerror_posix.h"
 #include "base/string_util.h"
 #include "base/sys_info.h"
 #include "base/threading/thread_local.h"
@@ -590,6 +591,8 @@ class ThreadLocalBooleanAutoReset {
 base::LazyInstance<ThreadLocalBoolean>::Leaky
     g_unchecked_malloc = LAZY_INSTANCE_INITIALIZER;
 
+// NOTE(shess): This is called when the malloc library noticed that the heap
+// is fubar.  Avoid calls which will re-enter the malloc library.
 void CrMallocErrorBreak() {
   g_original_malloc_error_break();
 
@@ -602,8 +605,11 @@ void CrMallocErrorBreak() {
     return;
 
   // A unit test checks this error message, so it needs to be in release builds.
-  PLOG(ERROR) <<
-      "Terminating process due to a potential for future heap corruption";
+  char buf[1024] =
+      "Terminating process due to a potential for future heap corruption: ";
+  size_t bufLen = strlen(buf);

[Mark Mentovai, 2012/11/12 22:45:10]

Nit: buf_len.

+  safe_strerror_r(errno, buf + bufLen, sizeof(buf) - bufLen);

[Mark Mentovai, 2012/11/12 22:45:10]

[safe_]strerror[_r] might wind up entering the allocator to access localized
messages. You can use the deprecated sys_errlist variable (along with sys_nerr),
but I’d just as soon drop the friendly string in this case and just use the
numeric value of errno.

For that matter, it’s a real pain to prove that the printf family can’t enter
the allocator for a given use either. snprintf with only integral and string
types SHOULD be safe.

[Scott Hess - ex-Googler, 2012/11/12 23:06:43]

Seems reasonable.
I actually recently had opportunity to audit that code, and AFAICT it will only
dynamically allocate in certain cases of floating-point output, and vector
output.  But, even so ... there's always MATH.

+  RAW_LOG(ERROR, buf);
 
   // Crash by writing to NULL+errno to allow analyzing errno from
   // crash dump info (setting a breakpad key would re-enter the malloc
@@ -629,6 +635,10 @@ void EnableTerminationOnHeapCorruption() {
     return;
   }
 
+  // Warm this up so that it doesn't require allocation when
+  // |CrMallocErrorBreak()| calls it.
+  ignore_result(g_unchecked_malloc.Get().Get());
+
   mach_error_t err = mach_override_ptr(
      (void*)malloc_error_break,
      (void*)&CrMallocErrorBreak,