Linux 14.04, sfml 2.3.2, and Valgrind: One tiny, mines or SFML's?

[doingit]

The memory leaked is very little, but I'm trying to determine if it's my portion of the code that is leaking or if it is the SFML; I don't mind if SFML leaks 1 block of 60 bytes, especially to prevent crashing, but I never target the tools for blame unless I've gone several hours/days at it.

After cleaning and researching for a while, I interpreted some of the information provided by Valgrind, and want to come to the assumption that it is a SFML leak. I have my doubts, so I am asking for confirmation if anyone understands the report and or SFML.

I've cleaned a lot and narrowed the Valgrind errors down to 1 block containing 60 bytes:
Valgrind Result:

==2672==
==2672== HEAP SUMMARY:
==2672==     in use at exit: 45,551 bytes in 417 blocks
==2672==   total heap usage: 39,234 allocs, 38,817 frees, 218,985,603 bytes allocated
==2672==
==2672== 60 bytes in 1 blocks are definitely lost in loss record 41 of 65
==2672==    at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2672==    by 0x44577DF: ??? (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x442BEB5: ??? (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x44282EC: ??? (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x4428379: glXGetConfig (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x409301C: sf::priv::GlxContext::selectBestVisual(_XDisplay*, unsigned int, sf::ContextSettings const&) (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4093D90: sf::priv::GlxContext::GlxContext(sf::priv::GlxContext*) (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4084269: sf::priv::GlContext::globalInit() (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4084B9F: sf::GlResource::GlResource() (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4086E4C: sf::Window::Window() (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x405F8FC: sf::RenderWindow::RenderWindow() (in /home/.../libsfml-graphics.so.2.3.2)
==2672==    by 0x804B1AB: App::App() (app.cpp:20)
==2672==
==2672== LEAK SUMMARY:
==2672==    definitely lost: 60 bytes in 1 blocks
==2672==    indirectly lost: 0 bytes in 0 blocks
==2672==      possibly lost: 0 bytes in 0 blocks
==2672==    still reachable: 45,491 bytes in 416 blocks
==2672==         suppressed: 0 bytes in 0 blocks
==2672== Reachable blocks (those to which a pointer was found) are not shown.
==2672== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2672==
==2672== For counts of detected and suppressed errors, rerun with: -v
==2672== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
 

There was another post back in 2010 about opengl context, hopefully that is relative to this leak as well.
http://en.sfml-dev.org/forums/index.php?topic=3354.0

Is this an SFML context leak?
Thanks.

[binary1248]

This is just your everyday "false positive" i.e. "not our problem" leak. Mesa/GLX/Xlib is known to be a bit dodgy here and there when it comes to memory management, so you are better off just adding this to your suppression list and moving on. If you check the documentation for glXGetConfig, you will see that it doesn't return any pointers/structures that can even be freed at a later point.

Similar 7.5 year old bug report (still has NEW status ): https://bugs.freedesktop.org/show_bug.cgi?id=17659

[doingit]

Thank you, appreciate the information.