STLでメモリーリーク？

C++ GCC STL

question:1174986855

valgrind でメモリーリークが検出されるのは、どうやら std::allocator が原因のようだ。

テストプログラム
#include <memory>

int main()
{
  std::allocator<int> allocator;
  int *ip = allocator.allocate(1);
  allocator.deallocate(ip, 1);
}
テスト環境
% uname -v
FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC 
% g++ --version
g++ (GCC) 3.3.6
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% g++ -Wall -g -o allocator allocator.cpp
テスト結果
% valgrind --leak-check=yes --show-reachable=yes ./allocator
==2756== Memcheck, a memory error detector for x86-linux.
==2756== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==2756== Using valgrind-2.1.0, a program supervision framework for x86-linux.
==2756== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==2756== Estimated CPU clock rate is 500 MHz
==2756== For more details, rerun with: -v
==2756== 
==2756== 
==2756== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2756== malloc/free: in use at exit: 320 bytes in 1 blocks.
==2756== malloc/free: 1 allocs, 0 frees, 320 bytes allocated.
==2756== For counts of detected errors, rerun with: -v
==2756== searching for pointers to 1 not-freed blocks.
==2756== checked 2189936 bytes.
==2756== 
==2756== 320 bytes in 1 blocks are still reachable in loss record 1 of 1
==2756==    at 0x3C0382F3: operator new(unsigned) (in /usr/local/lib/valgrind/vgpreload_memcheck.so)
==2756==    by 0x3C0B7FC1: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (stl_alloc.h:108)
==2756==    by 0x3C0B7EDB: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (stl_alloc.h:550)
==2756==    by 0x3C0B7C48: std::__default_alloc_template<true, 0>::allocate(unsigned) (stl_alloc.h:357)
==2756== 
==2756== LEAK SUMMARY:
==2756==    definitely lost: 0 bytes in 0 blocks.
==2756==    possibly lost:   0 bytes in 0 blocks.
==2756==    still reachable: 320 bytes in 1 blocks.
==2756==         suppressed: 0 bytes in 0 blocks.

3.3 系列では、効率化の為か複雑(?)な処理をしているようだが（未読）、そこにバグがあるのか、効率化の為の仕様なのかはわからない。（気が向いたら読んでみるかも。）
ちなみに、3.4 系列では、単純に new/delete を呼ぶだけになっているので、メモリーリークは検出されなくなっている。

続く…かも？