Forum > General

Finishing thread does not release Virtual memory

<< < (3/5) > >>


--- Quote from: jollytall on January 11, 2022, 11:58:55 am ---They finish normally, no memory leak, etc..

--- End quote ---
Or none that you know of....

Run your app under valgrind.
Compile with debug info enabled: dwarf  (ideally enabled for packages too, use "Additions and Overrides" to add -gw )

--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---valgrind --tool=memcheck  ./project1

Also, its possible that memory is allocated, and only freed when your app shuts down => no memleak, but growing mem usage.

E.g. if you add objects to a global list, and you (including any unit used by you) free all of it in a "finalization" block.

Thanks Martin,

Honestly, I never used vargrind before and it does not seem to be an easy tool. I get many errors and possibly lost and still reachable bytes. E.g. a summary:
==27332== LEAK SUMMARY:
==27332==    definitely lost: 0 bytes in 0 blocks
==27332==    indirectly lost: 0 bytes in 0 blocks
==27332==      possibly lost: 608 bytes in 2 blocks
==27332==    still reachable: 15,497 bytes in 149 blocks
==27332==         suppressed: 0 bytes in 0 blocks
I need more time to understand it, but most of them are in libcrypto (openssl) and libc. I don't know what I can do with them, and whether it can keep the reserved large virtual memory locked for few Kbyte of still reachable memory.

It will be a long task to figure it all out... Maybe it is easier to cron a daily restart and the problem is gone :-), but I do not like a solution like that.


--- Quote from: jollytall on January 11, 2022, 12:57:51 pm ---@marcov,
I think it is unlikely. I call the same object type with the same create parameters many times. They should allocate the same memory, so it should fit in to an earlier one

--- End quote ---

Unless a smaller came inbetween and partially filled the  large hole, so that the now smaller hole doesn't fit the next major allocation anymore . Anyway, try to recycle some larger memory allocations e.g. using a tthreadlist), and see if that changes behaviour.

Wait..wait..waitfor! Use waitfor as already mentioned.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version