Memory Leaks in Minimal.cpp Sample Program wxWidgers 3.1.5

[Jason Liam]

Hi, I have an app which works fine. But when I use valgrind on it to look for memory leaks it gives many such leaks. To reproduce the problem, I tried using valgrind on the minimal.cpp that was provided within the samples directory. And there too valgrind reports many memory leaks. Is memory leak an inherent part of wxWidgets? Or the things that valgrind reports as memory leaks are not relevant in this case. Some of the sample output from valgrind is given below. The problem is that I have a large program/project that reports a large amount of memory leaks even though I have made sure there are no such leaks from my end. For example, I have two parts of the program. First is a console app which is the main logic of the program and consists of several classes. When I use valgrind on that console app separately it reports no memory leaks. But then when I use wxWidgets as the main thread and do that console app work in a worker thread then valgrind reports many memory leaks. Is there a way to remove these memory leaks at least that are coming due to wxWidgets? In my program I have a list and it has custom elements. Also I have a button which says clear and when the user clicks on that button the old data from the list is cleared using DestroyChildren() and then new data is added to the list. Here the problem as seen in the system monitor is that every time I clear the data by pressing the button, the app's memory usage is increased by around 5MB even though the new data that is being filled in the list is exactly the same as the old one. So it should not increase the memory usage by so much. I am using Ubuntu 18.04.

==11588== 36,832 bytes in 1 blocks are still reachable in loss record 8,638 of 8,643
==11588==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11588==    by 0xB869D7C: ??? (in /usr/lib/x86_64-linux-gnu/libfreetype.so.6.15.0)
==11588==    by 0xB869DC5: ??? (in /usr/lib/x86_64-linux-gnu/libfreetype.so.6.15.0)
==11588==    by 0xB8B91E8: ??? (in /usr/lib/x86_64-linux-gnu/libfreetype.so.6.15.0)
==11588==    by 0xB86AABA: FT_Load_Glyph (in /usr/lib/x86_64-linux-gnu/libfreetype.so.6.15.0)
==11588==    by 0x6448EE5: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11510.0)
==11588==    by 0x6449B51: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11510.0)
==11588==    by 0x63F47D3: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11510.0)
==11588==    by 0x63F49F4: cairo_scaled_font_glyph_extents (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11510.0)
==11588==    by 0x618675F: ??? (in /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.4000.14)
==11588==    by 0x6C78EA3: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.4000.14)
==11588==    by 0xCCC98D0: ??? (in /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10702.0)

--------------------------------------------------------------------------------------------------------------------------

==11588== 96 bytes in 1 blocks are still reachable in loss record 7,262 of 8,643
==11588==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11588==    by 0x7375C30: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
==11588==    by 0x70FD789: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x7103A91: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x7103D64: g_type_register_static_simple (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x57E9BB9: gtk_orientable_get_type (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x56A2970: gtk_box_get_type (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x56A2BFE: gtk_box_new (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==    by 0x22C606: MyApp::OnInit() (minimal.cpp:124)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,263 of 8,643
==11588==    at 0x7104AB4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EB782: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EF70A: g_param_spec_enum (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x57E9B45: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x70FDBB0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70FFA79: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x7101367: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,264 of 8,643
==11588==    at 0x7104AB4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EB782: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EF379: g_param_spec_int (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x56A1F29: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==    by 0x22C606: MyApp::OnInit() (minimal.cpp:124)
==11588==    by 0x4910B1: wxEntry(int&, wchar_t**) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,265 of 8,643
==11588==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11588==    by 0x7375C30: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
==11588==    by 0x70FD789: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x7103A91: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E14E7: g_enum_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x58F3F5A: gtk_baseline_position_get_type (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x56A1F7F: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,266 of 8,643
==11588==    at 0x7104AB4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EB782: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EF70A: g_param_spec_enum (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x56A1FCC: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==    by 0x22C606: MyApp::OnInit() (minimal.cpp:124)
==11588==    by 0x4910B1: wxEntry(int&, wchar_t**) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,267 of 8,643
==11588==    at 0x7104AB4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EB782: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EF3F9: g_param_spec_uint (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x56A20CB: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==    by 0x22C606: MyApp::OnInit() (minimal.cpp:124)
==11588==    by 0x4910B1: wxEntry(int&, wchar_t**) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,268 of 8,643
==11588==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11588==    by 0x7375C30: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
==11588==    by 0x70FD789: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x7103A91: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E14E7: g_enum_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x58F431A: gtk_pack_type_get_type (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x56A20D7: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,269 of 8,643
==11588==    at 0x7104AB4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EB782: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EF70A: g_param_spec_enum (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x56A2121: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==    by 0x22C606: MyApp::OnInit() (minimal.cpp:124)
==11588==    by 0x4910B1: wxEntry(int&, wchar_t**) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==
==11588== 96 bytes in 1 blocks are still reachable in loss record 7,270 of 8,643
==11588==    at 0x7104AB4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EB782: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70EF379: g_param_spec_int (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x56A2178: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
==11588==    by 0x7101438: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E7727: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x70E78E8: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==11588==    by 0x24E531: wxTopLevelWindowGTK::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==    by 0x22E95E: wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&) (frame.h:31)
==11588==    by 0x22C700: MyFrame::MyFrame(wxString const&) (minimal.cpp:142)
==11588==    by 0x22C606: MyApp::OnInit() (minimal.cpp:124)
==11588==    by 0x4910B1: wxEntry(int&, wchar_t**) (in /homedir/username/Documents/wxWidgets-3.1.5/samples/minimal/program)
==11588==

---------------------------------------------------------------------------------------------------------------------------------------------------------------

==11588== LEAK SUMMARY:
==11588==    definitely lost: 8,024 bytes in 29 blocks
==11588==    indirectly lost: 13,562 bytes in 414 blocks
==11588==      possibly lost: 4,990 bytes in 52 blocks
==11588==    still reachable: 2,292,302 bytes in 26,303 blocks
==11588==                       of which reachable via heuristic:
==11588==                         length64           : 6,680 bytes in 107 blocks
==11588==                         newarray           : 2,128 bytes in 53 blocks
==11588==         suppressed: 0 bytes in 0 blocks
==11588==
==11588== ERROR SUMMARY: 560 errors from 56 contexts (suppressed: 0 from 0)

[Igor Korot]

Hi,

On Mon, Jul 19, 2021 at 8:29 AM Jason Liam <jlam...@gmail.com> wrote:
>
> Hi, I have an app which works fine. But when I use valgrind on it to look for memory leaks it gives many such leaks. To reproduce the problem, I tried using valgrind on the minimal.cpp that was provided within the samples directory. And there too valgrind reports many memory leaks. Is memory leak an inherent part of wxWidgets? Or the things that valgrind reports as memory leaks are not relevant in this case. Some of the sample output from valgrind is given below. The problem is that I have a large program/project that reports a large amount of memory leaks even though I have made sure there are no such leaks from my end. For example, I have two parts of the program. First is a console app which is the main logic of the program and consists of several classes. When I use valgrind on that console app separately it reports no memory leaks. But then when I use wxWidgets as the main thread and do that console app work in a worker thread then valgrind reports many memory leaks. Is there a way to remove these memory leaks at least that are coming due to wxWidgets? In my program I have a list and it has custom elements. Also I have a button which says clear and when the user clicks on that button the old data from the list is cleared using DestroyChildren() and then new data is added to the list. Here the problem as seen in the system monitor is that every time I clear the data by pressing the button, the app's memory usage is increased by around 5MB even though the new data that is being filled in the list is exactly the same as the old one. So it should not increase the memory usage by so much. I am using Ubuntu 18.04.

Wrong list!
You need to complain to GTK devs.

Here is the link: https://discourse.gnome.org/
However, those are here since forever and so I doubt they will ever be fixed.

Thank you.

> --
> Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
> ---
> You received this message because you are subscribed to the Google Groups "wx-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/CA%2BuK%3DSAwJJBrkZt%2ByL%2Bt10DyD6NwZWrQ0qzLtkHkoJer%3DO9fvg%40mail.gmail.com.

[Sean]

I also saw different memory issues of wxWidgets.

For example, consider the following scenario.
A panel with a button, pressing the button opens a MessageBox.
There is only an OK button.
Then when you click okay and go back to the panel, you will see that the memory usage has increased.
If you do this constantly, the memory will increase constantly.

There is no memory allocation during these processes.

[Vadim Zeitlin]

On Tue, 20 Jul 2021 01:42:30 +0300 Sean wrote:

S> For example, consider the following scenario.
S> A panel with a button, pressing the button opens a MessageBox.
S> There is only an OK button.
S> Then when you click okay and go back to the panel, you will see that the
S> memory usage has increased.
S> If you do this constantly, the memory will increase constantly.
S>
S> There is no memory allocation during these processes.

Please try reproducing this in a simple example and open a bug if you
manage to do it because this is definitely not supposed to happen and is
very different from one off leaks that aren't really a problem and
could/should be suppressed by using an appropriate suppression file.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Vadim Zeitlin]

On Mon, 19 Jul 2021 18:59:06 +0530 Jason Liam wrote:

JL> Hi, I have an app which works fine. But when I use valgrind on it to look
JL> for memory leaks it gives many such leaks. To reproduce the problem, I
JL> tried using valgrind on the minimal.cpp that was provided within the
JL> samples directory. And there too valgrind reports many memory leaks. Is
JL> memory leak an inherent part of wxWidgets? Or the things that valgrind
JL> reports as memory leaks are not relevant in this case. Some of the sample
JL> output from valgrind is given below.

There are no real memory leaks in the minimal sample, so you should create
a suppression file using it and then use it when debugging your own
program.

You could also consider address sanitizer (ASAN) which is typically a
better alternative to valgrind nowadays and, whether you use valgrind or
ASAN, you should get debug symbols for the GTK and related libraries, such
as FreeType and Cairo, to get something useful in the allocation stacks.

JL> The problem is that I have a large program/project that reports a large
JL> amount of memory leaks even though I have made sure there are no such
JL> leaks from my end.

This is a very optimistic statement.

JL> Here the problem as seen in the system monitor is that every time I clear
JL> the data by pressing the button, the app's memory usage is increased by
JL> around 5MB even though the new data that is being filled in the list is
JL> exactly the same as the old one. So it should not increase the memory usage
JL> by so much. I am using Ubuntu 18.04.

This looks very much like a leak in your program.

[Jason Liam]

@VZ I used ASAN on my program without changing anything in the program and the following is the output I got after I closed the app. Is there a way to remove these leaks and are they from the pre installed libraries or due to my code so that i can remove them?

=================================================================
==5685==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24320 byte(s) in 38 object(s) allocated from:
    #0 0x7f3dd23eef30 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef30)
    #1 0x7f3dcf8e9998  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d998)

Direct leak of 6656 byte(s) in 26 object(s) allocated from:
    #0 0x7f3dd23eeb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f3dcf8e98ed  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d8ed)

Indirect leak of 56032 byte(s) in 1751 object(s) allocated from:
    #0 0x7f3dd23eeb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f3dcf8d7fef  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0xbfef)

Indirect leak of 28116 byte(s) in 2198 object(s) allocated from:
    #0 0x7f3dd2387538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
    #1 0x7f3dcf8e92f4 in FcValueSave (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d2f4)

Indirect leak of 22304 byte(s) in 697 object(s) allocated from:
    #0 0x7f3dd23eed28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f3dcf8e9fd8  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1dfd8)

Indirect leak of 15648 byte(s) in 489 object(s) allocated from:
    #0 0x7f3dd23eed28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f3dcf8e95c4  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d5c4)

Indirect leak of 3648 byte(s) in 114 object(s) allocated from:
    #0 0x7f3dd23eed28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f3dcf8e9440  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d440)

Indirect leak of 912 byte(s) in 19 object(s) allocated from:
    #0 0x7f3dd23eeb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f3dcf8e3acd in FcLangSetCreate (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x17acd)

Indirect leak of 128 byte(s) in 4 object(s) allocated from:
    #0 0x7f3dd23eed28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f3dcf8e94b9  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d4b9)

SUMMARY: AddressSanitizer: 157764 byte(s) leaked in 5336 allocation(s).

[gunter.ko...@gmail.com]

If you manage to convince the libfontconfig programmers to fix these issues you would do me a big favour, too,.

But I cannot guarantee that all of those are actual memory leaks or if some fonts deliberately stay available on closing the program so other programs can use them without loading them anew.

[Vadim Zeitlin]

On Thu, 22 Jul 2021 12:20:31 +0530 Jason Liam wrote:

JL> @VZ I used ASAN on my program without changing anything in the program and
JL> the following is the output I got after I closed the app. Is there a way to
JL> remove these leaks and are they from the pre installed libraries or due to
JL> my code so that i can remove them?

You need to use a suppression file. There is already one here:

https://github.com/wxWidgets/wxWidgets/blob/master/misc/suppressions/lsan

so you can just use it, but you also need to install the debug symbols for
the system libraries for the suppressions to match.