stacktrace: Fix memory leak inside of libheaptrace.so

libheaptrace.so internally uses alloc/dealloc functions, but those are
captured by our internal allocation accounting by having 'hook_guard'.

However, 'utils::string_split' is currently called before setting
'hook_guard' to true so the internal memory allocation is captured and
reported as follows.

  $ heaptrace samples/sample_leak.out
  [heaptrace] initialized for /proc/2730/maps (sample_leak.out)
  [heaptrace]   finalized for /proc/2730/maps (sample_leak.out)
  =================================================================
  [heaptrace] dump allocation sorted by 'size' for /proc/2730/maps (sample_leak.out)
  === backtrace honggyukim#1 === [count/peak: 1/1] [size/peak: 32 bytes/32 bytes] [age: 53.583 us]
   0 [0xffffb1065290] operator new(unsigned long) +0x20
   1 [0xffffb106aad8] void std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11... +0x6a
   2 [0xffffb106a760] ./libheaptrace.so (+0xffffb106a760)
   3 [0xffffb1067adc] ./libheaptrace.so (+0xffffb1067adc)
   4 [0xffffb1064d78] ./libheaptrace.so (+0xffffb1064d78)
   5 [0xffffb10921d8] /lib/ld-linux-aarch64.so.1 (+0xffffb10921d8)
   6 [0xffffb0f16d84] /lib64/libc.so.6 (+0xffffb0f16d84)
   7 [0xffffb0f16f14] /lib64/libc.so.6 (+0xffffb0f16f14)
          ...

This patch is to fix this problem by moving it after 'hook_guard' is
set to true.

Fixed: honggyukim#15
Signed-off-by: Honggyu Kim <[email protected]>

stacktrace.cc

@@ -357,10 +357,10 @@ void dump_stackmap(const char *sort_keys, bool flamegraph)
 	if (stackmap.empty())
 		return;
 
-	std::vector<std::string> sort_key_vec = utils::string_split(sort_keys, ',');
-
 	tfs->hook_guard = true;
 
+	std::vector<std::string> sort_key_vec = utils::string_split(sort_keys, ',');
+
 	// sort the stack trace based on the count and then total_size
 	std::vector<std::pair<stack_trace_t, stack_info_t>> sorted_stack;
 	{