Even the simplest SDL program leaks memory, as reported by valgrind.
This is the program:
#include "SDL.h"
int main(int argc, char* args[])
{
SDL_Init(SDL_INIT_VIDEO);
SDL_Quit();
return 0;
}
This is the output of valgrind:
==1161== Memcheck, a memory error detector
==1161== Copyright © 2002-2015, and GNU GPL’d, by Julian Seward et al.
==1161== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1161== Command: ./(…omitted…)
==1161==
–1161-- WARNING: Serious error when reading debug info
–1161-- When reading debug info from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0:
–1161-- Ignoring non-Dwarf2/3/4 block in .debug_info
–1161-- WARNING: Serious error when reading debug info
–1161-- When reading debug info from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0:
–1161-- Last block truncated in .debug_info; ignoring
–1161-- WARNING: Serious error when reading debug info
–1161-- When reading debug info from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0:
–1161-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
==1161== Syscall param writev(vector[…]) points to uninitialised byte(s)
==1161== at 0x579EFE0: __writev_nocancel (syscall-template.S:84)
==1161== by 0x8C86F28: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==1161== by 0x8C8731C: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==1161== by 0x8C873A4: xcb_writev (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==1161== by 0x5F3C54D: _XSend (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==1161== by 0x5F3CA41: _XReply (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==1161== by 0x5F2760E: XInternAtom (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==1161== by 0x544EAEA: SetWindowBordered (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x544F8F1: X11_CreateWindow (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x5441148: SDL_CreateWindow_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x5440F34: SDL_VideoInit_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x53A8396: SDL_InitSubSystem_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== Address 0xc18ddb3 is 35 bytes inside a block of size 16,384 alloc’d
==1161== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1161== by 0x5F2C722: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==1161== by 0x5074E69: ??? (in /usr/NX/scripts/vgl/librrfaker.so)
==1161== by 0x50768D1: XOpenDisplay (in /usr/NX/scripts/vgl/librrfaker.so)
==1161== by 0x544DDB4: X11_CreateDevice (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x5440EE0: SDL_VideoInit_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x53A8396: SDL_InitSubSystem_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==1161== by 0x40060D: main (in (…omitted…))
==1161==
==1161==
==1161== HEAP SUMMARY:
==1161== in use at exit: 112,141 bytes in 474 blocks
==1161== total heap usage: 10,970 allocs, 10,496 frees, 672,833,828 bytes allocated
==1161==
==1161== LEAK SUMMARY:
==1161== definitely lost: 17,920 bytes in 3 blocks
==1161== indirectly lost: 0 bytes in 0 blocks
==1161== possibly lost: 0 bytes in 0 blocks
==1161== still reachable: 94,221 bytes in 471 blocks
==1161== suppressed: 0 bytes in 0 blocks
==1161== Rerun with --leak-check=full to see details of leaked memory
==1161==
==1161== For counts of detected and suppressed errors, rerun with: -v
==1161== Use --track-origins=yes to see where uninitialised values come from
==1161== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 1 from 1)
So my question is: Does SDL have to leak memory? Is there any workaround to stop the leakage? Thanks.
Environment:
- Ubuntu 16.04 64 bit.
- SDL 2.0
- g++ 5.4.0
- Valgrind 3.11.0
A follow-up: this is the valgrind report of leakage on another Linux:
Environment:
- Ubuntu 18.04 64 bit.
- SDL 2.0
- g++ 7.3.0
- Valgrind 3.13.0