Утечка памяти при печати значения с плавающей запятой

В моем MacOS(El Capitan 10.11.5) я написал очень простой код, подобный этому:

#include <iostream>

int main(int argc, const char * argv[]) {
    // insert code here...
    std::cout << "Hello, World!\n" << 4.f << std::endl;
    return 0;
}

Затем я построил и протестировал утечку памяти:

g++ ./test.cpp
valgrind --leak-check=full ./a.out

Результат показывает, что есть утечка памяти!

==46149== Memcheck, a memory error detector
==46149== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==46149== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==46149== Command: ./a.out
==46149==
--46149-- run: /usr/bin/dsymutil "./a.out" warning: no debug symbols in executable (-arch x86_64)
test4
==46149==
==46149== HEAP SUMMARY:
==46149==     in use at exit: 26,357 bytes in 194 blocks
==46149==   total heap usage: 260 allocs, 66 frees, 32,133 bytes allocated
==46149==
==46149== 148 (80 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 44 of 67
==46149==    at 0x100009EBB: malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==46149==    by 0x1002AC8D6: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002AD21F: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002A9877: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002D23E6: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002FB6C8: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002DF914: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002DF973: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x1002CFE1D: snprintf_l (in /usr/lib/system/libsystem_c.dylib)
==46149==    by 0x10003C752: std::__1::num_put<char, std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > >::do_put(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, std::__1::ios_base&, char, double) const (in /usr/lib/libc++.1.dylib)
==46149==    by 0x1000229AD: std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(float) (in /usr/lib/libc++.1.dylib)
==46149==    by 0x100000FF7: main (in ./a.out)
==46149==
==46149== 2,064 bytes in 1 blocks are possibly lost in loss record 61 of 67
==46149==    at 0x10000A17C: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==46149==    by 0x1005E2EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D6182: protocols() (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D6093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D3C13: gc_init (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005DB24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005E8132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D683C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D6300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D62E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D62E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==46149==    by 0x1005D62E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==46149==
==46149== LEAK SUMMARY:
==46149==    definitely lost: 80 bytes in 1 blocks
==46149==    indirectly lost: 68 bytes in 2 blocks
==46149==      possibly lost: 2,064 bytes in 1 blocks
==46149==    still reachable: 4,096 bytes in 1 blocks
==46149==         suppressed: 20,049 bytes in 189 blocks
==46149== Reachable blocks (those to which a pointer was found) are not shown.
==46149== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==46149==
==46149== For counts of detected and suppressed errors, rerun with: -v
==46149== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 18 from 18)

Если я изменю значение с плавающей запятой (4.f) на целочисленное значение (4), то утечек точно не будет. Я также проверил на машине Linux, и нет никаких проблем.

Так как это очень простой код, похоже, что на моем Mac есть какая-то проблема. Кто-нибудь знает эту проблему?

добавлены результаты Mac OS Instruments

Как показано на следующих снимках экрана, печать плавающего значения приводит к утечке памяти.

Печать с плавающей точкой вызывает утечку памяти

Целочисленная печать не приводит к утечке памяти

0 ответов

Другие вопросы по тегам