2013-07-16 36 views
12

Valgrind의 다음 코드에서, 스레드 당 분명히 하나, 유출 된 블록을보고 :thread_local을 사용할 때 gcc 4.8.1의 메모리 누수가 발생합니까?

#include <iostream> 
#include <thread> 
#include <mutex> 
#include <list> 
#include <chrono> 

std::mutex cout_mutex; 

struct Foo 
{ 
    Foo() 
    { 
     std::lock_guard<std::mutex> lock(cout_mutex); 
     std::cout << __PRETTY_FUNCTION__ << '\n'; 
    } 

    ~Foo() 
    { 
     std::lock_guard<std::mutex> lock(cout_mutex); 
     std::cout << __PRETTY_FUNCTION__ << '\n'; 
    } 

    void 
    hello_world() 
    { 
     std::lock_guard<std::mutex> lock(cout_mutex); 
     std::cout << __PRETTY_FUNCTION__ << '\n'; 
    } 
}; 

void 
hello_world_thread() 
{ 
    thread_local Foo foo; 

    // must access, or the thread local variable may not be instantiated 
    foo.hello_world(); 

    // keep the thread around momentarily 
    std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
} 

int main() 
{ 
    for (int i = 0; i < 100; ++i) 
    { 
     std::list<std::thread> threads; 

     for (int j = 0; j < 10; ++j) 
     { 
      std::thread thread(hello_world_thread); 
      threads.push_back(std::move(thread)); 
     } 

     while (! threads.empty()) 
     { 
      threads.front().join(); 
      threads.pop_front(); 
     } 
    } 
} 

컴파일러 버전 :

$ g++ --version 
g++ (GCC) 4.8.1 
Copyright (C) 2013 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. 

GCC 빌드 옵션 :

--enable-shared 
--enable-threads=posix 
--enable-__cxa_atexit 
--enable-clocale=gnu 
--enable-cxx-flags='-fno-omit-frame-pointer -g3' 
--enable-languages=c,c++ 
--enable-libstdcxx-time=rt 
--enable-checking=release 
--enable-build-with-cxx 
--disable-werror 
--disable-multilib 
--disable-bootstrap 
--with-system-zlib 

프로그램 컴파일 옵션 :

g++ -std=gnu++11 -Og -g3 -Wall -Wextra -fno-omit-frame-pointer thread_local.cc 

Valgrind의 버전 :

$ valgrind --version 
valgrind-3.8.1 

Valgrind의 옵션 : Valgrind의 출력

valgrind --leak-check=full --verbose ./a.out > /dev/null 

테일 엔드 :

:
==1786== HEAP SUMMARY: 
==1786==  in use at exit: 24,000 bytes in 1,000 blocks 
==1786== total heap usage: 3,604 allocs, 2,604 frees, 287,616 bytes allocated 
==1786== 
==1786== Searching for pointers to 1,000 not-freed blocks 
==1786== Checked 215,720 bytes 
==1786== 
==1786== 24,000 bytes in 1,000 blocks are definitely lost in loss record 1 of 1 
==1786== at 0x4C29969: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:329) 
==1786== by 0x4E8E53E: __cxa_thread_atexit (atexit_thread.cc:119) 
==1786== by 0x401036: hello_world_thread() (thread_local.cc:34) 
==1786== by 0x401416: std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() (functional:1732) 
==1786== by 0x4EE4830: execute_native_thread_routine (thread.cc:84) 
==1786== by 0x5A10E99: start_thread (pthread_create.c:308) 
==1786== by 0x573DCCC: clone (clone.S:112) 
==1786== 
==1786== LEAK SUMMARY: 
==1786== definitely lost: 24,000 bytes in 1,000 blocks 
==1786== indirectly lost: 0 bytes in 0 blocks 
==1786==  possibly lost: 0 bytes in 0 blocks 
==1786== still reachable: 0 bytes in 0 blocks 
==1786==   suppressed: 0 bytes in 0 blocks 
==1786== 
==1786== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) 
--1786-- 
--1786-- used_suppression:  2 dl-hack3-cond-1 
==1786== 
==1786== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) 

생성자와 소멸자는 각 스레드에 대해 한 번 실행 된

$ ./a.out | grep 'Foo::Foo' | wc -l 
1000 

$ ./a.out | grep hello_world | wc -l 
1000 

$ ./a.out | grep 'Foo::~Foo' | wc -l 
1000 

참고 : 사용자가 만든 스레드의 수를 변경하는 경우

  • 는 유출 블록의 수는 스레드의 수를 일치합니다.
  • 코드는 일 수 있습니다.은 GCC가 구현 된 경우 리소스 재사용 (즉, 누출 된 블록)을 허용합니다. 프로그램 실행이 약 10 초 정도 소요 인해 sleep_for() 호출에 thread_local Foo foo;
  • 다음 Valgrind의의 스택 트레이스에서
  • , thread_local.cc:34 라인입니다.

이 메모리 누수가 GCC에 있는지, 내 구성 옵션 결과인지 또는 내 프로그램의 일부 버그입니까?

+3

이것은 완벽하게 구성된 질문의 빛나는 예입니다. – GManNickG

+0

왜'정적'을 사용합니까? – stefan

+0

고정. 나는 valgrind를 다시 실행했지만 불행히도 누출은 여전히 ​​존재합니다. – user2224952

답변

2

누출이 동적 초기화에서 오는 것으로 보인다.

thread_local int num=4; //static initialization 

마지막 예는 누출되지 않는다 : 여기

int와 일례이다. 나는 2 개의 스레드와 전혀 누출없이 시도했다.

하지만 지금 :

int func() 
{ 
    return 4; 
} 
thread_local int num2=func(); //dynamic initialization 

이 하나의 누출!

thread_local Foo *foo = new Foo; //dynamic initialization 

없음이 할 스레드 실행의 끝에서 잊지 :

delete foo; 

를 그러나 2 개는 total heap uage: 8 allocs, 6 frees, 428 bytes allocated 제공 스레드 ...

난 당신이 같은 해결 방법을 사용하는 것이 좋습니다 것으로 마지막 예를 하나의 문제로 말하십시오 : 삭제 전에 스레드가 종료되면 어떻게 될까요? 누설 다시 ...

좋은 해결책이없는 것 같습니다. 어쩌면 우리는 그 것을 g++ 개발자에게보고해야합니까?

+0

이 문제에 대한 버그 보고서를 만들었습니다. [link] (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57914) – user2224952

0

는 thread_local 제거하고 hello_world_thread 내

void 
    hello_world_thread() 
    { 
     Foo foo; 

     // must access, or the thread local variable may not be instantiated 
     foo.hello_world(); 

     // keep the thread around momentarily 
     std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
    } 

foo는 모든 스레드에 대한 로컬 스택에 있어야 다음 코드를 사용해보십시오. 그래서 모든 쓰레드는 foo의 복사본을 유지할 것이다. 명시 적으로이를 thread_local로 표시 할 필요가 없습니다. thread_local은 정적 또는 네임 스페이스 수준 변수와 같은 것이 있지만 각 변수가 모든 스레드에 대해 자체 복사본을 유지하기를 원할 때 컨텍스트에서 사용해야합니다.

감사 Kajal

+0

실제 사용 사례는 다음과 같을 수 있습니다. 'Foo & foo() { thread_local Foo foo; return foo; } 공극 hello_world_thread() { 경우 (some_condition) { foo는() 인 Hello_World().; } } 스레드 로컬 개체는 스레드에서 참조하는 경우에만 인스턴스화 (및 소멸)됩니다. 잘못된 코드 위치에서 코드 예제를 최소화하고 복잡성을 추가 한 것으로 보입니다 (즉, 스레드 구성 동작). – user2224952