Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Memory Leaks in sf::RenderWindow  (Read 5335 times)

0 Members and 1 Guest are viewing this topic.

zac

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Memory Leaks in sf::RenderWindow
« on: August 04, 2008, 11:19:18 pm »
Hi again,
because of (minor) memory leaks in my program I started to test sf::RenderWindow (I wanted to see if it leaks memory).
I am using Linux (Ubuntu 64-bit)...

Code: [Select]

int main()
{
while(1)
{
VideoMode v(100,100);
RenderWindow* rw = new RenderWindow(v,"blllaaaaa",Style::Close|Style::Resize,4);
delete rw;
}
}


The memory this code commits is increasing slowly, but steadily.
Is there any way to avoid that? I'm working on a GUI project where in some cases, new RenderWindows are created (like e.g. for a Message Box).
Without spawning windows very fast (it takes a rather long time, you can count the windows manually^^), the program takes 11.0 MB RAM (starting with 5.5 MB RAM) after 7 Minutes.
By the way, the memory leaked per Window seems to increase depending on the size of the window.
I can only estimate the amout of memory leaked per Window, but I think it is between 1 K and 2 K... 270 Windows are something like 250 KB.

It might be a problem with the OS (global GL context or something similar), but the OS does not seem to deallocate the memory, even after half an hour (when the memory the program uses is about 40 MB)...

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Memory Leaks in sf::RenderWindow
« Reply #1 on: August 05, 2008, 02:40:04 am »
I've already seen this kind of leak with OpenGL stuff (probably the driver), but if I remember correctly it was under Windows only.

Can you use a software like valgrind to track the leak more precisely inside SFML's code ? If necessary, you can build the debug libs using "make DEBUGBUILD=yes".
Laurent Gomila - SFML developer

Avency

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Memory Leaks in sf::RenderWindow
« Reply #2 on: August 05, 2008, 11:21:56 am »
I noticed that a while ago, but I'm not sure if it really is a SFML related problem.
Anyway, here is the valgrind result (Ubuntu 8.04.1 32-bit, but I remember that the same happened with 8.10 alpha versions):

Code: [Select]
int main(int argc, char **argv)
{
sf::VideoMode Mode(640, 480);

sf::RenderWindow* RenderWindow = new sf::RenderWindow(Mode,"Test",sf::Style::Close|sf::Style::Resize);

delete RenderWindow;

return 0;
}


This is the valgrind output (run with  --leak-check=full):
Code: [Select]
==9284== Memcheck, a memory error detector.
==9284== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==9284== Using LibVEX rev 1804, a library for dynamic binary translation.
==9284== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==9284== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==9284== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==9284== For more details, rerun with: -v
==9284==
==9284== Syscall param writev(vector[...]) points to uninitialised byte(s)
==9284==    at 0x40007F2: (within /lib/ld-2.7.so)
==9284==    by 0x4718EC2: (within /usr/lib/libxcb.so.1.0.0)
==9284==    by 0x47194AA: (within /usr/lib/libxcb.so.1.0.0)
==9284==    by 0x47195DE: (within /usr/lib/libxcb.so.1.0.0)
==9284==    by 0x471AB36: xcb_wait_for_reply (in /usr/lib/libxcb.so.1.0.0)
==9284==    by 0x44B61EA: _XReply (in /usr/lib/libX11.so.6.2.0)
==9284==    by 0x4499661: XInternAtom (in /usr/lib/libX11.so.6.2.0)
==9284==    by 0x406482A: sf::priv::WindowImplX11::Initialize() (WindowImplX11.cpp:691)
==9284==    by 0x4066306: sf::priv::WindowImplX11::WindowImplX11(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings&) (WindowImplX11.cpp:304)
==9284==    by 0x406107C: sf::priv::WindowImpl::New(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings&) (WindowImpl.cpp:113)
==9284==    by 0x405E0A8: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (Window.cpp:121)
==9284==    by 0x40EF5E8: sf::RenderWindow::RenderWindow(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (RenderWindow.cpp:51)
==9284==  Address 0x533c034 is 4,380 bytes inside a block of size 8,556 alloc'd
==9284==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==9284==    by 0x4719130: xcb_connect_to_fd (in /usr/lib/libxcb.so.1.0.0)
==9284==    by 0x471BA50: xcb_connect (in /usr/lib/libxcb.so.1.0.0)
==9284==    by 0x44B5716: _XConnectXCB (in /usr/lib/libX11.so.6.2.0)
==9284==    by 0x449E028: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9284==    by 0x4063399: sf::priv::WindowImplX11::OpenDisplay(bool) (WindowImplX11.cpp:1139)
==9284==    by 0x4066A79: sf::priv::WindowImplX11::WindowImplX11() (WindowImplX11.cpp:71)
==9284==    by 0x40610DA: sf::priv::WindowImpl::New() (WindowImpl.cpp:80)
==9284==    by 0x405D82C: sf::Window::ForceContextInit() (Window.cpp:391)
==9284==    by 0x405DF96: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (Window.cpp:104)
==9284==    by 0x40EF5E8: sf::RenderWindow::RenderWindow(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (RenderWindow.cpp:51)
==9284==    by 0x804C5C5: main (main.cpp:53)
==9284==
==9284== Invalid read of size 4
==9284==    at 0x4015220: (within /lib/ld-2.7.so)
==9284==    by 0x4005C69: (within /lib/ld-2.7.so)
==9284==    by 0x4007A97: (within /lib/ld-2.7.so)
==9284==    by 0x4011543: (within /lib/ld-2.7.so)
==9284==    by 0x400D5D5: (within /lib/ld-2.7.so)
==9284==    by 0x4010F5D: (within /lib/ld-2.7.so)
==9284==    by 0x4729C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9284==    by 0x400D5D5: (within /lib/ld-2.7.so)
==9284==    by 0x472A2BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9284==    by 0x4729B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9284==    by 0x448C786: (within /usr/lib/libX11.so.6.2.0)
==9284==    by 0x448CA6E: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0)
==9284==  Address 0x562fea0 is 24 bytes inside a block of size 25 alloc'd
==9284==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9284==    by 0x4008031: (within /lib/ld-2.7.so)
==9284==    by 0x4011543: (within /lib/ld-2.7.so)
==9284==    by 0x400D5D5: (within /lib/ld-2.7.so)
==9284==    by 0x4010F5D: (within /lib/ld-2.7.so)
==9284==    by 0x4729C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9284==    by 0x400D5D5: (within /lib/ld-2.7.so)
==9284==    by 0x472A2BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9284==    by 0x4729B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9284==    by 0x448C786: (within /usr/lib/libX11.so.6.2.0)
==9284==    by 0x448CA6E: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0)
==9284==    by 0x448CE6C: XCreatePixmap (in /usr/lib/libX11.so.6.2.0)
==9284==
==9284== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 71 from 1)
==9284== malloc/free: in use at exit: 359,080 bytes in 803 blocks.
==9284== malloc/free: 5,906 allocs, 5,103 frees, 3,470,686 bytes allocated.
==9284== For counts of detected errors, rerun with: -v
==9284== searching for pointers to 803 not-freed blocks.
==9284== checked 815,648 bytes.
==9284==
==9284==
==9284== 262,140 bytes in 1 blocks are possibly lost in loss record 100 of 100
==9284==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9284==    by 0x45AAD56: (within /usr/lib/libGL.so.169.12)
==9284==
==9284== LEAK SUMMARY:
==9284==    definitely lost: 0 bytes in 0 blocks.
==9284==      possibly lost: 262,140 bytes in 1 blocks.
==9284==    still reachable: 96,940 bytes in 802 blocks.
==9284==         suppressed: 0 bytes in 0 blocks.
==9284== Reachable blocks (those to which a pointer was found) are not shown.
==9284== To see them, rerun with: --leak-check=full --show-reachable=yes

 

anything