当C++异常未被捕获时，ValgND检测到错误

我注意到valgrind报告了以下最小示例中可能存在的内存泄漏：

#include <stdexcept>
int main() {
  try {
    throw std::logic_error("test");
  }
  catch (std::exception& e) {
    std::string msg("test2 ");
    msg.append(e.what());
    throw std::logic_error(msg);
  }
  return 0;
}

是的，这很正常。15.3/9如果未找到匹配的处理程序，则调用函数std:：terminate；在调用std:：terminate之前，堆栈是否展开由15.5.1实现定义。此外，terminate的默认行为是调用abort，它在不运行任何全局变量（如cin或cout）的析构函数的情况下终止程序。

==8640== Memcheck, a memory error detector
==8640== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8640== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==8640== Command: ./a.out
==8640== 
terminate called after throwing an instance of 'std::logic_error'
  what():  test2 test
==8640== 
==8640== HEAP SUMMARY:
==8640==     in use at exit: 354 bytes in 4 blocks
==8640==   total heap usage: 6 allocs, 2 frees, 417 bytes allocated
==8640== 
==8640== 29 bytes in 1 blocks are possibly lost in loss record 1 of 4
==8640==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640==    by 0x4EF13B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x4EF2AE0: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x4EF2EF7: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x400BA7: main (test.cpp:4)
==8640== 
==8640== 37 bytes in 1 blocks are possibly lost in loss record 2 of 4
==8640==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640==    by 0x4EF13B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x4EF1F7A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x4EF2013: std::string::reserve(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x4EF225E: std::string::append(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x400CC6: main (test.cpp:8)
==8640== 
==8640== 144 bytes in 1 blocks are possibly lost in loss record 3 of 4
==8640==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640==    by 0x4E944E2: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x400B83: main (test.cpp:4)
==8640== 
==8640== 144 bytes in 1 blocks are possibly lost in loss record 4 of 4
==8640==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640==    by 0x4E944E2: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640==    by 0x400CD0: main (in /home/wush/Test/a.out)
==8640== 
==8640== LEAK SUMMARY:
==8640==    definitely lost: 0 bytes in 0 blocks
==8640==    indirectly lost: 0 bytes in 0 blocks
==8640==      possibly lost: 354 bytes in 4 blocks
==8640==    still reachable: 0 bytes in 0 blocks
==8640==         suppressed: 0 bytes in 0 blocks
==8640== 
==8640== For counts of detected and suppressed errors, rerun with: -v
==8640== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 1 from 1)
Aborted (core dumped)