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
-
+        // passing nullptr, 0 forces allocation of a unique buffer we can free
-		static size_t abi_name_len = 100;
+        // fixing MAINT-8724 on OSX 10.14
-		static char* abi_name_buf = (char*)malloc(abi_name_len);
+		int status = -1;
-			// warning: above is voodoo inferred from the GCC manual,
+		char* name = abi::__cxa_demangle(type.name(), nullptr, 0, &status);
-			// do NOT change
+        std::string result(name ? name : type.name());
-
+        free(name);
-		int status;
+        return result;
-			// 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();
-
 #elif LL_WINDOWS
 		// DevStudio: type_info::name() includes the text "class " at the start