Почему у моей shared_ptr утечка памяти? - PullRequest
1 голос
/ 31 декабря 2011

Я пытаюсь использовать C ++ 11 std :: tr1 :: shared_ptr для управления указателями SDL_Surface. Обратите внимание, я не использую Boost. Я определил удалитель для shared_ptr, чтобы использовать SDL_FreeSurface.

Объявлен как:

class Engine {
private:
  std::tr1::shared_ptr<SDL_Surface> _scr;
  std::tr1::shared_ptr<SDL_Surface> _bg;  

Определяется (в ктор двигателя) как:

_scr = std::tr1::shared_ptr<SDL_Surface>( SDL_SetVideoMode(Data::SCR_WIDTH,
                                                          Data::SCR_HEIGHT,
                                                        32, SDL_SWSURFACE),
                                            SurfaceDeleter<SDL_Surface>());

  _bg = std::tr1::shared_ptr<SDL_Surface>(IMG_Load(Data::IM_BACKGROUND),
                                         SurfaceDeleter<SDL_Surface>());

Пользовательский удалитель:

template<typename T>
class SurfaceDeleter{ 
public:
  void operator() (T*& d) const {
    if(d){
      SDL_FreeSurface(d);
    }
  }
};

Единственный объект, содержащий shared_ptr, это Engine. Shared_ptr использовался так:

  SDL_BlitSurface(_bg.get(), nullptr, _scr.get(), nullptr);
  SDL_Flip(_scr.get());

Результаты Valgrind:

==3648== 8 bytes in 2 blocks are definitely lost in loss record 16 of 292
==3648==    at 0x402A018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3648==    by 0x431FBE0: strdup (in /lib/libc-2.14.1.so)

==3648== 1 bytes in 1 blocks are definitely lost in loss record 1 of 292
==3648==    at 0x402A018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3648==    by 0x494A590: _XlcDefaultMapModifiers (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x494A99A: XSetLocaleModifiers (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x4097CDB: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==3648==    by 0x4083868: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
==3648==    by 0x40594D9: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.3)
==3648==    by 0x42C3212: (below main) (in /lib/libc-2.14.1.so)

==3648== 980 (68 direct, 912 indirect) bytes in 1 blocks are definitely lost in loss record 258 of 292
==3648==    at 0x402A102: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3648==    by 0x49402A6: ??? (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x49407A2: ??? (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x494212F: ??? (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x49429BA: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x4965957: _XlcUtf8Loader (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x494A793: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x494A8F1: _XlcCurrentLC (in /usr/lib/libX11.so.6.3.0)
==3648==    by 0x4097CDB: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==3648==    by 0x4083868: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
==3648==    by 0x40594D9: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.3)
==3648==    by 0x42C3212: (below main) (in /lib/libc-2.14.1.so)

1 Ответ

2 голосов
/ 06 мая 2012

Запустите valgrind с помощью --track-origins=yes, чтобы он показал, где была выделена утечка памяти.

Вы также можете использовать --leak-check=full и --leak-resolution=high (хотя последнее должно быть по умолчанию)

...