Recent

« previous next »
Pages: 1 [2]

Author Topic: [SOLVED]How to find source of memory leak  (Read 2219 times)

AlexK

  • Full Member
  • ***
  • Posts: 101
Re: How to find source of memory leak
« Reply #15 on: September 21, 2025, 07:29:57 pm »
Quote from: rnfpc on September 21, 2025, 01:17:08 pm
It seems that the most important part of valgrind output is:
Code: Pascal  [Select][+][-]
  1. Heap dump by heaptrc unit of .../mycalc_prog
  2. 12446 memory blocks allocated : 2541877/2560584
  3. 12446 memory blocks freed     : 2541877/2560584
If this is  ok, all is well.
One can ignore the leak summary.

That's heaptrc output, not Valgrind's.
Valgrind is for C programs and languages written in C.

There are no memory leaks in this program.
Logged

rnfpc

  • Full Member
  • ***
  • Posts: 118
Re: How to find source of memory leak
« Reply #16 on: September 22, 2025, 03:20:33 am »
@AlexK Pls confirm that following valgrind output is to be ignored:

Code: Pascal  [Select][+][-]
  1. ==8980== LEAK SUMMARY:
  2. ==8980==    definitely lost: 15,792 bytes in 48 blocks
  3. ==8980==     indirectly lost: 50,222 bytes in 2,022 blocks
  4. ==8980==      possibly lost: 6,023 bytes in 37 blocks
  5. ==8980==    still reachable: 3,306,793 bytes in 44,584 blocks
  6. ==8980==        suppressed: 0 bytes in 0 blocks
  7. ==8980== Rerun with --leak-check=full to see details of leaked memory
  8.  
Logged

Thaddy

  • Hero Member
  • *****
  • Posts: 18684
  • Jungle wars. And failing health it seems.
Re: How to find source of memory leak
« Reply #17 on: September 22, 2025, 07:05:05 am »
Rerun with --leak-check=full to see details of leaked memory

You still did not do that?
That memory is related to startup code and fpc's memory manager and will be returned to the OS on shutdown of the program.
Trust heaptrc, that handles it correctly. Valgrind hallucinates again.
We are not herre to explain the shortcomings of valgrind if you did not even do what valgrind advised:
Rerun with --leak-check=full to see details of leaked memory
« Last Edit: September 22, 2025, 07:17:51 am by Thaddy »
Logged
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

Thaddy

  • Hero Member
  • *****
  • Posts: 18684
  • Jungle wars. And failing health it seems.
Re: How to find source of memory leak
« Reply #18 on: September 22, 2025, 02:56:56 pm »
Substract these values: 2541877 from 2560584
Logged
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

PascalDragon

  • Hero Member
  • *****
  • Posts: 6272
  • Compiler Developer
Re: How to find source of memory leak
« Reply #19 on: September 22, 2025, 10:17:36 pm »
Quote from: AlexK on September 21, 2025, 07:29:57 pm
That's heaptrc output, not Valgrind's.
Valgrind is for C programs and languages written in C.

valgrind is also usable with FPC compiler programs, especially if they're compiled with -gv.
Logged

AlexK

  • Full Member
  • ***
  • Posts: 101
Re: How to find source of memory leak
« Reply #20 on: September 22, 2025, 10:45:19 pm »
Quote from: PascalDragon on September 22, 2025, 10:17:36 pm
valgrind is also usable with FPC compiler programs, especially if they're compiled with -gv.

Yes, -gv option advised third time in this thread.

Valgrind can trace only Linux's system calls mmap and sbrk from FPC's memory manager if -gv wasn't used. I guess.
« Last Edit: September 22, 2025, 11:16:42 pm by AlexK »
Logged

rnfpc

  • Full Member
  • ***
  • Posts: 118
Re: How to find source of memory leak
« Reply #21 on: September 24, 2025, 03:11:58 am »
Following is the output after building with -gv option and running valgrind with --leak-check=full :

Code: Pascal  [Select][+][-]
  1. $ valgrind --leak-check=full ./mycalc_prog
  2. ==3898== Memcheck, a memory error detector
  3. ==3898== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
  4. ==3898== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
  5. ==3898== Command: ./mycalc_prog
  6. ==3898==
  7. ==3898==
  8. ==3898== HEAP SUMMARY:
  9. ==3898==     in use at exit: 2,889,177 bytes in 43,324 blocks
  10. ==3898==   total heap usage: 152,304 allocs, 108,980 frees, 14,367,095 bytes allocated
  11. ==3898==
  12. ==3898== 10 bytes in 1 blocks are definitely lost in loss record 480 of 8,268
  13. ==3898==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
  14. ==3898==    by 0x4FB05D8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  15. ==3898==    by 0x4FCABDE: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  16. ==3898==    by 0x4A32271: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  17. ==3898==    by 0x4A34E09: gtk_icon_info_load_icon (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  18. ==3898==    by 0x4A34F59: gtk_icon_theme_load_icon (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  19. ==3898==    by 0x4A30554: gtk_icon_set_render_icon (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  20. ==3898==    by 0x4B8A3BB: gtk_widget_render_icon (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  21. ==3898==    by 0x4A4483B: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  22. ==3898==    by 0x4A44880: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  23. ==3898==    by 0x4F0D2F0: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7400.6)
  24. ==3898==    by 0x4F1FD2C: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7400.6)
  25. ==3898==
  26. ==3898== 30 bytes in 1 blocks are possibly lost in loss record 2,748 of 8,268
  27. ==3898==    at 0x48465EF: calloc (vg_replace_malloc.c:1328)
  28. ==3898==    by 0x4FB0630: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  29. ==3898==    by 0x50C5C0D: pango_language_from_string (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  30. ==3898==    by 0x50C5D00: pango_language_get_default (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  31. ==3898==    by 0x50C0F93: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  32. ==3898==    by 0x4F2EDE8: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7400.6)
  33. ==3898==    by 0x4F12D2F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7400.6)
  34. ==3898==    by 0x4F143FB: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7400.6)
  35. ==3898==    by 0x4F15000: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7400.6)
  36. ==3898==    by 0x50C2FD2: pango_font_map_create_context (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  37. ==3898==    by 0x489DD2B: gdk_pango_context_get_for_screen (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.33)
  38. ==3898==    by 0x4B84637: gtk_widget_create_pango_context (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
  39. ==3898==
  40. ==3898== 32 bytes in 2 blocks are possibly lost in loss record 4,058 of 8,268
  41. ==3898==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
  42. ==3898==    by 0x563E98D: FcFontSetCreate (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  43. ==3898==    by 0x5644F95: FcFontSetSort (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  44. ==3898==    by 0x56E4EFC: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  45. ==3898==    by 0x4FD4C5C: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  46. ==3898==    by 0x52DA1F4: start_thread (pthread_create.c:442)
  47. ==3898==    by 0x5359B3F: clone (clone.S:100)
  48. ==3898==
  49. ==3898== 96 bytes in 1 blocks are possibly lost in loss record 7,074 of 8,268
  50. ==3898==    at 0x48465EF: calloc (vg_replace_malloc.c:1328)
  51. ==3898==    by 0x4FB0630: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  52. ==3898==    by 0x4FBCA2E: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  53. ==3898==    by 0x56E8129: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  54. ==3898==    by 0x56E51C8: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  55. ==3898==    by 0x50C6D0C: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  56. ==3898==    by 0x50C7A83: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  57. ==3898==    by 0x50C8BEF: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  58. ==3898==    by 0x50CDDE8: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  59. ==3898==    by 0x50CE125: pango_layout_get_size (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  60. ==3898==    by 0x50CCE31: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  61. ==3898==    by 0x50CDEFD: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  62. ==3898==
  63. ==3898== 96 bytes in 1 blocks are possibly lost in loss record 7,075 of 8,268
  64. ==3898==    at 0x48465EF: calloc (vg_replace_malloc.c:1328)
  65. ==3898==    by 0x4FB0630: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  66. ==3898==    by 0x4FBCA2E: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  67. ==3898==    by 0x56E8129: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  68. ==3898==    by 0x50BB802: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  69. ==3898==    by 0x50CB83D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  70. ==3898==    by 0x50CDEFD: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  71. ==3898==    by 0x543A71B: ??? (in /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.5000.12)
  72. ==3898==    by 0x50C6D2D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  73. ==3898==    by 0x50C7A83: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  74. ==3898==    by 0x50C8BEF: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  75. ==3898==    by 0x50CDDE8: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  76. ==3898==
  77. ==3898== 368 bytes in 1 blocks are possibly lost in loss record 7,875 of 8,268
  78. ==3898==    at 0x48465EF: calloc (vg_replace_malloc.c:1328)
  79. ==3898==    by 0x4010C62: calloc (rtld-malloc.h:44)
  80. ==3898==    by 0x4010C62: allocate_dtv (dl-tls.c:401)
  81. ==3898==    by 0x40116CD: _dl_allocate_tls (dl-tls.c:670)
  82. ==3898==    by 0x52DADAE: allocate_stack (allocatestack.c:423)
  83. ==3898==    by 0x52DADAE: pthread_create@@GLIBC_2.34 (pthread_create.c:650)
  84. ==3898==    by 0x4FFEFC3: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  85. ==3898==    by 0x4FD4F97: g_thread_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  86. ==3898==    by 0x56E8194: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  87. ==3898==    by 0x56E51C8: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  88. ==3898==    by 0x50C6D0C: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  89. ==3898==    by 0x50C7A83: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  90. ==3898==    by 0x50C8BEF: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  91. ==3898==    by 0x50CDDE8: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  92. ==3898==
  93. ==3898== 368 bytes in 1 blocks are possibly lost in loss record 7,876 of 8,268
  94. ==3898==    at 0x48465EF: calloc (vg_replace_malloc.c:1328)
  95. ==3898==    by 0x4010C62: calloc (rtld-malloc.h:44)
  96. ==3898==    by 0x4010C62: allocate_dtv (dl-tls.c:401)
  97. ==3898==    by 0x40116CD: _dl_allocate_tls (dl-tls.c:670)
  98. ==3898==    by 0x52DADAE: allocate_stack (allocatestack.c:423)
  99. ==3898==    by 0x52DADAE: pthread_create@@GLIBC_2.34 (pthread_create.c:650)
  100. ==3898==    by 0x4FFEFC3: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  101. ==3898==    by 0x4FD4F97: g_thread_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  102. ==3898==    by 0x56E8194: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  103. ==3898==    by 0x50BB802: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  104. ==3898==    by 0x50CB83D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  105. ==3898==    by 0x50CDEFD: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  106. ==3898==    by 0x543A71B: ??? (in /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.5000.12)
  107. ==3898==    by 0x50C6D2D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  108. ==3898==
  109. ==3898== 368 bytes in 1 blocks are possibly lost in loss record 7,877 of 8,268
  110. ==3898==    at 0x48465EF: calloc (vg_replace_malloc.c:1328)
  111. ==3898==    by 0x4010C62: calloc (rtld-malloc.h:44)
  112. ==3898==    by 0x4010C62: allocate_dtv (dl-tls.c:401)
  113. ==3898==    by 0x40116CD: _dl_allocate_tls (dl-tls.c:670)
  114. ==3898==    by 0x52DADAE: allocate_stack (allocatestack.c:423)
  115. ==3898==    by 0x52DADAE: pthread_create@@GLIBC_2.34 (pthread_create.c:650)
  116. ==3898==    by 0x4FFEFC3: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  117. ==3898==    by 0x4FD5850: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  118. ==3898==    by 0x4FD5CC2: g_thread_pool_push (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  119. ==3898==    by 0x54F4B58: g_task_run_in_thread (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7400.6)
  120. ==3898==    by 0x54914C8: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7400.6)
  121. ==3898==    by 0x554B7CB: g_bus_get (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7400.6)
  122. ==3898==    by 0x5559005: g_bus_watch_name (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.7400.6)
  123. ==3898==    by 0x8DF93A3: ??? (in /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so)
  124. ==3898==
  125. ==3898== 512 bytes in 2 blocks are possibly lost in loss record 7,978 of 8,268
  126. ==3898==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
  127. ==3898==    by 0x563EA67: FcFontSetAdd (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  128. ==3898==    by 0x5644EAC: FcFontSetSort (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  129. ==3898==    by 0x56E4EFC: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  130. ==3898==    by 0x4FD4C5C: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  131. ==3898==    by 0x52DA1F4: start_thread (pthread_create.c:442)
  132. ==3898==    by 0x5359B3F: clone (clone.S:100)
  133. ==3898==
  134. ==3898== 5,002 (1,536 direct, 3,466 indirect) bytes in 2 blocks are definitely lost in loss record 8,218 of 8,268
  135. ==3898==    at 0x484682F: realloc (vg_replace_malloc.c:1437)
  136. ==3898==    by 0x56474D8: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  137. ==3898==    by 0x5647B59: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  138. ==3898==    by 0x56445DB: FcFontRenderPrepare (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  139. ==3898==    by 0x5644809: FcFontSetMatch (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  140. ==3898==    by 0x56E4F92: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  141. ==3898==    by 0x4FD4C5C: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.6)
  142. ==3898==    by 0x52DA1F4: start_thread (pthread_create.c:442)
  143. ==3898==    by 0x5359B3F: clone (clone.S:100)
  144. ==3898==
  145. ==3898== 6,243 (512 direct, 5,731 indirect) bytes in 1 blocks are definitely lost in loss record 8,225 of 8,268
  146. ==3898==    at 0x484682F: realloc (vg_replace_malloc.c:1437)
  147. ==3898==    by 0x56474D8: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  148. ==3898==    by 0x5647C60: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  149. ==3898==    by 0x51BF523: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0)
  150. ==3898==    by 0x543EA48: ??? (in /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.5000.12)
  151. ==3898==    by 0x56E7EFD: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  152. ==3898==    by 0x56E51C8: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  153. ==3898==    by 0x50C6D0C: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  154. ==3898==    by 0x50C7A83: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  155. ==3898==    by 0x50C8BEF: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  156. ==3898==    by 0x50CDDE8: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  157. ==3898==    by 0x50CE125: pango_layout_get_size (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  158. ==3898==
  159. ==3898== 6,378 (512 direct, 5,866 indirect) bytes in 1 blocks are definitely lost in loss record 8,226 of 8,268
  160. ==3898==    at 0x484682F: realloc (vg_replace_malloc.c:1437)
  161. ==3898==    by 0x56474D8: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  162. ==3898==    by 0x5647C60: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  163. ==3898==    by 0x51BF523: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0)
  164. ==3898==    by 0x543EA48: ??? (in /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.5000.12)
  165. ==3898==    by 0x56E7EFD: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.5000.12)
  166. ==3898==    by 0x50BB802: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  167. ==3898==    by 0x50CB83D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  168. ==3898==    by 0x50CDEFD: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  169. ==3898==    by 0x543A71B: ??? (in /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.5000.12)
  170. ==3898==    by 0x50C6D2D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  171. ==3898==    by 0x50C7A83: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12)
  172. ==3898==
  173. ==3898== 8,807 (6,656 direct, 2,151 indirect) bytes in 26 blocks are definitely lost in loss record 8,243 of 8,268
  174. ==3898==    at 0x48417B4: malloc (vg_replace_malloc.c:381)
  175. ==3898==    by 0x5647431: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  176. ==3898==    by 0x5647C60: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  177. ==3898==    by 0x564955D: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  178. ==3898==    by 0x5651D8A: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  179. ==3898==    by 0x5CE2BBF: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.8.10)
  180. ==3898==    by 0x5CE38D6: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.8.10)
  181. ==3898==    by 0x5CE4BE0: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.8.10)
  182. ==3898==    by 0x5CE6328: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.8.10)
  183. ==3898==    by 0x5CDA2AE: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.8.10)
  184. ==3898==    by 0x5CDDB6C: XML_ParseBuffer (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.8.10)
  185. ==3898==    by 0x564EEB1: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0)
  186. ==3898==
  187. ==3898== LEAK SUMMARY:
  188. ==3898==    definitely lost: 9,226 bytes in 31 blocks
  189. ==3898==    indirectly lost: 17,214 bytes in 712 blocks
  190. ==3898==      possibly lost: 1,870 bytes in 10 blocks
  191. ==3898==    still reachable: 2,744,859 bytes in 41,606 blocks
  192. ==3898==         suppressed: 0 bytes in 0 blocks
  193. ==3898== Reachable blocks (those to which a pointer was found) are not shown.
  194. ==3898== To see them, rerun with: --leak-check=full --show-leak-kinds=all
  195. ==3898==
  196. ==3898== For lists of detected and suppressed errors, rerun with: -s
  197. ==3898== ERROR SUMMARY: 13 errors from 13 contexts (suppressed: 0 from 0)
  198.  
Logged

AlexK

  • Full Member
  • ***
  • Posts: 101
Re: How to find source of memory leak
« Reply #22 on: September 24, 2025, 05:49:35 am »
All are traces of allocations from system shared libraries. May be false positives.

C programs may allocate memory that's used as a global var and kept alive until process exit.
« Last Edit: September 24, 2025, 09:01:37 am by AlexK »
Logged

Thaddy

  • Hero Member
  • *****
  • Posts: 18684
  • Jungle wars. And failing health it seems.
Re: How to find source of memory leak
« Reply #23 on: September 24, 2025, 09:19:33 am »
These are all internal allocations done by libraries. These libraries do:
a. their own memory allocations, not by the fpc memory manager
b. de-allocate on program shutdown

They may well be "true" leaks, but then they need to be fixed in the library sources and not in fpc code.
Since these libraries are well established, however, I'd consider them harmless and by design.
From the Pascal side, there is nothing you can do about that. Trust heaptrc, as I wrote before.
There is really no point in pursuing ghosts. The leaks disappear on unloading of the libraries anyway.

Another way of showing that is monitoring the memory by top or similar. You will see that the program releases all its memory on shutdown unless heaptrc finds leaks. And those you can fix.

Frankly, you are acting a bit naive. All the answerers were given. Valgrind seems too complex for you to interpret its reports correctly.
« Last Edit: September 24, 2025, 09:22:30 am by Thaddy »
Logged
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

rnfpc

  • Full Member
  • ***
  • Posts: 118
Re: How to find source of memory leak
« Reply #24 on: September 24, 2025, 10:22:27 am »
Code: Pascal  [Select][+][-]
  1. Frankly, you are acting a bit naive.
  2. All the answers were given.
  3. Valgrind seems too complex for you to interpret its reports correctly.
I am not a professional (only a hobbyist) and I am here to learn. Comments and explanations by you and other have been very helpful and I appreciate that very much. This forum is really an interesting and educative one. I am marking this question as solved.
Logged

AlexK

  • Full Member
  • ***
  • Posts: 101
Re: [SOLVED]How to find source of memory leak
« Reply #25 on: September 24, 2025, 12:08:00 pm »
In general "memory leaks" are overrated.

And it seems that in every language implementation GC is always an unfinished feature, that needs enhancements, rewrites, for decades.
Logged

rnfpc

  • Full Member
  • ***
  • Posts: 118
Re: [SOLVED]How to find source of memory leak
« Reply #26 on: September 24, 2025, 12:45:21 pm »
I find that if both -gv and  -gh options are checked, the program does not compile. The message is:
Code: Pascal  [Select][+][-]
  1. Compile Project, Target: myexefile: Exit code 1, Errors: 1
  2. Error: /usr/bin/ppcx64 returned an error exit code
Logged

Thaddy

  • Hero Member
  • *****
  • Posts: 18684
  • Jungle wars. And failing health it seems.
Re: [SOLVED]How to find source of memory leak
« Reply #27 on: September 24, 2025, 01:02:47 pm »
You never should mix different ways to debug memory at the same time.
Why don't you listen? Your problem is marked solved?
There is honestly nothing wrong and you have been warned about Valgrind.
Logged
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.
Pages: 1 [2]
« previous next »
 

TinyPortal © 2005-2018