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

Andy Green andy at warmcat.com
Mon Oct 27 09:01:11 CET 2014



On 27 October 2014 15:53:32 GMT+08:00, satya gowtham kudupudi <satyagowtham.k at gmail.com> wrote:
>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?

No, it should be taken care of at the connection close.

But when you exit, you must destroy the lws context (which forces the remaining connections closed and cleans them up).

If the leaks are real, can you associate them with anything you're particularly doing while it's running?

-Andy

>--
>Gowtham
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
>http://ml.libwebsockets.org/mailman/listinfo/libwebsockets




More information about the Libwebsockets mailing list