I found a leak, viewer-release found it too, let's use their fix

It's close enough to mine, although I disagree with using 0 for a pointer
instead of using nullptr, but alas, mergeability.

This damn leak happened at least every log line on Linux and Mac since
the dawn of time for the viewer... Disgusting.
Well, not every log line, but every log line mentioning a class, which is
most these days.

indra/llcommon/llerror.cpp

@@ -252,23 +252,13 @@ namespace
 	{
 #ifdef __GNUC__
 		// GCC: type_info::name() returns a mangled class name,st demangle
-
-		static size_t abi_name_len = 100;
-		static char* abi_name_buf = (char*)malloc(abi_name_len);
-			// warning: above is voodoo inferred from the GCC manual,
-			// do NOT change
-
-		int status;
-			// We don't use status, and shouldn't have to pass apointer to it
-			// but gcc 3.3 libstc++'s implementation of demangling is broken
-			// and fails without.
-			
-		char* name = abi::__cxa_demangle(type.name(),
-										abi_name_buf, &abi_name_len, &status);
-			// this call can realloc the abi_name_buf pointer (!)
-
-		return name ? name : type.name();
-
+        // passing nullptr, 0 forces allocation of a unique buffer we can free
+        // fixing MAINT-8724 on OSX 10.14
+		int status = -1;
+		char* name = abi::__cxa_demangle(type.name(), nullptr, 0, &status);
+        std::string result(name ? name : type.name());
+        free(name);
+        return result;
 #elif LL_WINDOWS
 		// DevStudio: type_info::name() includes the text "class " at the start