[Libwebsockets] leaking memory. confirmed with libwebsockets-test-server

satya gowtham kudupudi satyagowtham.k at gmail.com
Mon Oct 27 08:53:32 CET 2014


Running my application using libwebsockets library with valgrind for 100
seconds gave the below heap report:

==5248== HEAP SUMMARY:
==5248==     in use at exit: 27,338 bytes in 19 blocks
==5248==   total heap usage: 6,427 allocs, 6,409 frees, 22,189,389 bytes
allocated
==5248==
==5248== 27,302 bytes in 17 blocks are definitely lost in loss record 3 of 3
==5248==    at 0x402A17C: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5248==    by 0x4071E1C: lws_allocate_header_table (in
/usr/local/lib/libwebsockets.so.5.0.0)
==5248==    by 0x406E9EA: libwebsocket_read (in
/usr/local/lib/libwebsockets.so.5.0.0)
==5248==    by 0x4079AB6: lws_server_socket_service (in
/usr/local/lib/libwebsockets.so.5.0.0)
==5248==    by 0x40703C7: libwebsocket_service_fd (in
/usr/local/lib/libwebsockets.so.5.0.0)
==5248==    by 0x4078093: lws_plat_service (in
/usr/local/lib/libwebsockets.so.5.0.0)
==5248==    by 0x4070552: libwebsocket_service (in
/usr/local/lib/libwebsockets.so.5.0.0)
==5248==    by 0x8058F73: WSServer::heart(WSServer*) (WSServer.cpp:1143)
==5248==    by 0x805CB5B: int std::_Bind_simple<int
(*(WSServer*))(WSServer*)>::_M_invoke<0u>(std::_Index_tuple<0u>)
(functional:1732)
==5248==    by 0x805CAA2: std::_Bind_simple<int
(*(WSServer*))(WSServer*)>::operator()() (functional:1720)
==5248==    by 0x805CA57: std::thread::_Impl<std::_Bind_simple<int
(*(WSServer*))(WSServer*)> >::_M_run() (thread:115)
==5248==    by 0x415EF4D: ??? (in
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==5248==
==5248== LEAK SUMMARY:
==5248==    definitely lost: 27,302 bytes in 17 blocks
==5248==    indirectly lost: 0 bytes in 0 blocks
==5248==      possibly lost: 0 bytes in 0 blocks
==5248==    still reachable: 36 bytes in 2 blocks
==5248==         suppressed: 0 bytes in 0 blocks
==5248== Reachable blocks (those to which a pointer was found) are not
shown.
==5248== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5248==
==5248== For counts of detected and suppressed errors, rerun with: -v
==5248== Use --track-origins=yes to see where uninitialised values come from
==5248== ERROR SUMMARY: 348 errors from 10 contexts (suppressed: 0 from 0)

Running valgrind --leak-check=yes libwebsockets-test-server gave following
report:

==5270== HEAP SUMMARY:
==5270==     in use at exit: 1,642 bytes in 3 blocks
==5270==   total heap usage: 3,331 allocs, 3,328 frees, 237,277 bytes
allocated
==5270==
==5270== 1,606 bytes in 1 blocks are definitely lost in loss record 3 of 3
==5270==    at 0x402A17C: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5270==    by 0x804F480: lws_allocate_header_table (in
/usr/local/bin/libwebsockets-test-server)
==5270==    by 0x805614E: lws_server_socket_service (in
/usr/local/bin/libwebsockets-test-server)
==5270==    by 0x804DBAB: libwebsocket_service_fd (in
/usr/local/bin/libwebsockets-test-server)
==5270==    by 0x8054743: lws_plat_service (in
/usr/local/bin/libwebsockets-test-server)
==5270==    by 0x804B5FC: main (in /usr/local/bin/libwebsockets-test-server)
==5270==
==5270== LEAK SUMMARY:
==5270==    definitely lost: 1,606 bytes in 1 blocks
==5270==    indirectly lost: 0 bytes in 0 blocks
==5270==      possibly lost: 0 bytes in 0 blocks
==5270==    still reachable: 36 bytes in 2 blocks
==5270==         suppressed: 0 bytes in 0 blocks
==5270== Reachable blocks (those to which a pointer was found) are not
shown.
==5270== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5270==
==5270== For counts of detected and suppressed errors, rerun with: -v
==5270== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Should I have to invoke any cleaning function after leaving
libwebsocket_service loop? Is there something like
lws_deallocate_header_table?

--
Gowtham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libwebsockets.org/pipermail/libwebsockets/attachments/20141027/9bdbc11a/attachment.html>


More information about the Libwebsockets mailing list