Community
Participate
Working Groups
To reproduce, run Eclipse with jemalloc. Then: 1. Create a new Java project, create a hello world snippet with a breakpoint at System.out.println(). 2. Debug the snippet, terminate the debug launch. 3. Switch to Debug perspective, then back to Java perspective. 4. Close Eclipse. 5. Observe jemalloc memory leak report for: Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new One of these is e.g.: [98304 bytes leaked] _init (??:0) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_valist (??:?) g_object_new (??:?) gtk_menu_init (/usr/src/debug/gtk+-3.22.30/gtk/gtkmenu.c:1340) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new (??:?) ?? (??:0) In our product (based on Eclipse 4.15) we see about 15 MB leaked over 12 hours of continuous debug and switch perspective operations.
When I track Menu creation and disposal, there are definitely dispose calls not coming from Eclipse; i.e. not all Menu objects receive a dispose() call. I don't know if this is causing the leak. In our test (that runs over long periods of time), I don't see an increasing number of undisposed Menu items when I repeat the test e.g. 20 times. The biggest leak report from our product (based on 4.15 so the namespace of the method is "GTK" and not "GTK3"): [7248384 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk_GTK_gtk_1menu_1new (??:?) 0x00007fffe31ee20e (??:0)
I also see leaks reported for the default SWT menu example snippet (with added menu disposal, just in case): public class SWTMenuExample { Display display; Shell shell; Menu menuBar, fileMenu, helpMenu; MenuItem fileMenuHeader, helpMenuHeader; MenuItem fileExitItem, fileSaveItem, helpGetHelpItem; Label label; public SWTMenuExample() { display = new Display(); shell = new Shell(display); shell.setText("Menu Example"); shell.setSize(300, 200); label = new Label(shell, SWT.CENTER); label.setBounds(shell.getClientArea()); menuBar = new Menu(shell, SWT.BAR); fileMenuHeader = new MenuItem(menuBar, SWT.CASCADE); fileMenuHeader.setText("&File"); fileMenu = new Menu(shell, SWT.DROP_DOWN); fileMenuHeader.setMenu(fileMenu); fileSaveItem = new MenuItem(fileMenu, SWT.PUSH); fileSaveItem.setText("&Save"); fileExitItem = new MenuItem(fileMenu, SWT.PUSH); fileExitItem.setText("E&xit"); helpMenuHeader = new MenuItem(menuBar, SWT.CASCADE); helpMenuHeader.setText("&Help"); helpMenu = new Menu(shell, SWT.DROP_DOWN); helpMenuHeader.setMenu(helpMenu); helpGetHelpItem = new MenuItem(helpMenu, SWT.PUSH); helpGetHelpItem.setText("&Get Help"); fileExitItem.addSelectionListener(new fileExitItemListener()); fileSaveItem.addSelectionListener(new fileSaveItemListener()); helpGetHelpItem.addSelectionListener(new helpGetHelpItemListener()); shell.setMenuBar(menuBar); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } menuBar.dispose(); display.dispose(); } class fileExitItemListener implements SelectionListener { public void widgetSelected(SelectionEvent event) { shell.close(); display.dispose(); } public void widgetDefaultSelected(SelectionEvent event) { shell.close(); display.dispose(); } } class fileSaveItemListener implements SelectionListener { public void widgetSelected(SelectionEvent event) { label.setText("Saved"); } public void widgetDefaultSelected(SelectionEvent event) { label.setText("Saved"); } } class helpGetHelpItemListener implements SelectionListener { public void widgetSelected(SelectionEvent event) { label.setText("No worries!"); } public void widgetDefaultSelected(SelectionEvent event) { label.setText("No worries!"); } } public static void main(String[] args) { int n = Integer.valueOf(args[0]); for (int i = 0; i < n; ++i) new SWTMenuExample(); } } E.g. when repeated 20 times, I see: [16384 bytes leaked] _init (??:0) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1bar_1new (??:?) ?? (??:0) [16384 bytes leaked] _init (??:0) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new (??:?) ?? (??:0) I'm not exactly sure this is the leak either though, as I don't find the exact same stack traces leaking less memory on fewer repetitions.
(In reply to Simeon Andreev from comment #2) > I also see leaks reported for the default SWT menu example snippet (with > added menu disposal, just in case): OK I see this was caused due to not exporting G_SLICE=always-malloc, with that the snippet doesn't show the leak. Eclipse itself still does (see steps from the description). I'll keep looking for an SWT snippet to reproduce the problem with.
I believe this snippet shows a leak (I'm not 100% sure its the same leak): public static void main(String[] args) { int n = 50; for (int j = 0; j < n; ++j) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Text bn = new Text(shell, SWT.FLAT); bn.setText("Right Click to see the popup menu"); Menu popupMenu = new Menu(bn); for (int i = 0; i < 14; ++i) { MenuItem newItem = new MenuItem(popupMenu, SWT.CASCADE); newItem.setText("New"); MenuItem refreshItem = new MenuItem(popupMenu, SWT.NONE); refreshItem.setText("Refresh"); MenuItem deleteItem = new MenuItem(popupMenu, SWT.NONE); deleteItem.setText("Delete"); Menu newMenu = new Menu(popupMenu); newItem.setMenu(newMenu); MenuItem shortcutItem = new MenuItem(newMenu, SWT.NONE); shortcutItem.setText("Shortcut"); MenuItem iconItem = new MenuItem(newMenu, SWT.NONE); iconItem.setText("Icon"); } MenuItem refreshItem = new MenuItem(popupMenu, SWT.NONE); refreshItem.setText("Refresh"); bn.setMenu(popupMenu); shell.open(); while (display.readAndDispatch()) { // process UI events } popupMenu.dispose(); display.dispose(); } } With n = 15, I see: [11520 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new (??:?) ?? (??:0) With n = 50, I see: [24576 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new (??:?) ?? (??:0) With n = 100, I see: [62976 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new (??:?) ?? (??:0) The snippet is taken from: http://www.java2s.com/Tutorial/Java/0280__SWT/CreatingaPopupMenu.htm Note that I see memory leaks reported also with GTK+ menu example snippet: https://developer.gnome.org/gtk-tutorial/stable/x1577.html#container However they don't increase if I wrap the main() code in a loop, at least not the ones reported with g_object_new() on the stack trace.
I believe I see similar leaks with the following GTK+ snippet: // gcc -g menu.c `pkg-config --cflags --libs gtk+-3.0` -o menu #include <gtk/gtk.h> int main(int argc, char *argv[]) { int j; for (j = 0; j < 10; ++j) { GtkWidget *window; GtkWidget *vbox; GtkWidget *menubar; GtkWidget *fileMenu; GtkWidget *fileMi; GtkWidget *quitMi; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); gtk_window_set_default_size(GTK_WINDOW(window), 300, 200); gtk_window_set_title(GTK_WINDOW(window), "Simple menu"); vbox = gtk_vbox_new(FALSE, 0); gtk_container_add(GTK_CONTAINER(window), vbox); menubar = gtk_menu_bar_new(); fileMenu = gtk_menu_new(); fileMi = gtk_menu_item_new_with_label("File"); quitMi = gtk_menu_item_new_with_label("Quit"); gtk_menu_item_set_submenu(GTK_MENU_ITEM(fileMi), fileMenu); gtk_menu_shell_append(GTK_MENU_SHELL(fileMenu), quitMi); gtk_menu_shell_append(GTK_MENU_SHELL(menubar), fileMi); gtk_box_pack_start(GTK_BOX(vbox), menubar, FALSE, FALSE, 0); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL); g_signal_connect(G_OBJECT(quitMi), "activate", G_CALLBACK(gtk_main_quit), NULL); gtk_widget_show_all(window); gtk_main(); } return 0; } Run the snippet and use File -> Quit, n times. I don't know how valid this is though, since the menu is calling gtk_main_quit(). I don't know if its expected to keep running code after that method... I was not able to reproduce the leaks with just menus doing nothing on click. Anyway jemalloc reports leaks in gtk_menu_init() such as: n = 10: [6912 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_valist (??:?) g_object_new (??:?) gtk_menu_init (/home/sandreev/git/gtk/gtk/gtk/gtkmenu.c:1342) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) ?? (??:0) __libc_start_main (/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274) ?? (??:0) n = 20: [15360 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_valist (??:?) g_object_new (??:?) gtk_menu_init (/home/sandreev/git/gtk/gtk/gtk/gtkmenu.c:1342) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) ?? (??:0) __libc_start_main (/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274) ?? (??:0) I do see gtk_menu_init() called also for other snippets, where I could not reproduce a leak. Alexander, do you have time to take a look here? I'm not sure if my snippet above is valid enough to use as a GTK+ memory leak report. But I'm also not sure what SWT is doing wrong, to cause the leak.
Improving on your snippet from Comment 4, I eventually arrived at this very simple one: -------- Display display = new Display(); Shell shell = new Shell(display); for (int j = 0; j < 100; j++) { Menu popupMenu = new Menu(shell); popupMenu.dispose(); } shell.open(); while (display.readAndDispatch()) { // process UI events } display.dispose(); -------- This perfectly scales with increasing the number of iterations. @Simeon would you continue investigating from here?
(In reply to Alexandr Miloslavskiy from comment #6) > @Simeon would you continue investigating from here? My main problem is the GTK+ snippet/codebase here. I'll look into your snippet and see what else SWT does with the menu, maybe its simpler now. It might take some time to get to this though.
I can add a bunch of menu creation calls, to a GTK+ snippet and I see the leak: // gcc -g menu.c `pkg-config --cflags --libs gtk+-3.0` -o menu #include <gtk/gtk.h> int main(int argc, char *argv[]) { int j; for (j = 0; j < 1; ++j) { GtkWidget *window; GtkWidget *vbox; GtkWidget *menubar; GtkWidget *fileMenu; GtkWidget *fileMi; GtkWidget *quitMi; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); gtk_window_set_default_size(GTK_WINDOW(window), 300, 200); gtk_window_set_title(GTK_WINDOW(window), "Simple menu"); vbox = gtk_vbox_new(FALSE, 0); gtk_container_add(GTK_CONTAINER(window), vbox); menubar = gtk_menu_bar_new(); fileMenu = gtk_menu_new(); fileMi = gtk_menu_item_new_with_label("File"); quitMi = gtk_menu_item_new_with_label("Quit"); gtk_menu_item_set_submenu(GTK_MENU_ITEM(fileMi), fileMenu); gtk_menu_shell_append(GTK_MENU_SHELL(fileMenu), quitMi); gtk_menu_shell_append(GTK_MENU_SHELL(menubar), fileMi); gtk_box_pack_start(GTK_BOX(vbox), menubar, FALSE, FALSE, 0); g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL); g_signal_connect(G_OBJECT(quitMi), "activate", G_CALLBACK(gtk_main_quit), NULL); gtk_widget_show_all(window); gtk_menu_new(); gtk_menu_new(); gtk_menu_new(); gtk_menu_new(); gtk_menu_new(); gtk_main(); } return 0; } I'm not sure how the menus are supposed to be freed, I'll check more GTK+ examples (the ones I've checked already don't do anything I can see to explicitly free a menu). I'll also search for a multiple menus example, maybe that will help.
I do see a leak, if I slightly modify the example seen here: https://zetcode.com/gui/gtk2/menusandtoolbars/ // gcc -g menu.c `pkg-config --cflags --libs gtk+-3.0` -o menu #include <gtk/gtk.h> int main(int argc, char *argv[]) { GtkWidget *window; GtkWidget *vbox; GtkWidget *menubar; GtkWidget *fileMenu; GtkWidget *fileMi, *fileMi1; GtkWidget *quitMi; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); gtk_window_set_default_size(GTK_WINDOW(window), 300, 200); gtk_window_set_title(GTK_WINDOW(window), "Simple menu"); vbox = gtk_vbox_new(FALSE, 0); gtk_container_add(GTK_CONTAINER(window), vbox); int k; for (k = 0; k < 5; ++k) { menubar = gtk_menu_bar_new(); fileMenu = gtk_menu_new(); fileMi = gtk_menu_item_new_with_label("File"); fileMi1 = gtk_menu_item_new_with_label("File1"); quitMi = gtk_menu_item_new_with_label("Quit"); gtk_menu_item_set_submenu(GTK_MENU_ITEM(fileMi1), fileMenu); gtk_menu_shell_append(GTK_MENU_SHELL(fileMenu), quitMi); gtk_menu_shell_append(GTK_MENU_SHELL(menubar), fileMi); gtk_box_pack_start(GTK_BOX(vbox), menubar, FALSE, FALSE, 0); g_signal_connect(G_OBJECT(quitMi), "activate", G_CALLBACK(gtk_main_quit), NULL); } g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL); gtk_widget_show_all(window); gtk_main(); } This seems to be "essential" to reproduce the leak: fileMi = gtk_menu_item_new_with_label("File"); fileMi1 = gtk_menu_item_new_with_label("File1"); I believe if "menubar" and "fileMenu" share a menu item, jemalloc doesn't report a growing leak (growing based on the loop iteration count). Oddly they don't share *both* menu items, so I'm not sure how the leak is not seen always. With 1 iteration of the loop (so normal code), the reported leak is: [768 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_valist (??:?) g_object_new (??:?) gtk_menu_init (/usr/src/debug/gtk+-3.22.30/gtk/gtkmenu.c:1340) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) ?? (??:0) __libc_start_main (/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274) ?? (??:0) Reading this doesn't make me hopeful: https://mail.gnome.org/archives/gtk-list/2011-March/msg00045.html > For dynamic menus, I think the best solution is to treat them like > static menus for the purposes of lifetime management, but to modify > them as they pop up. Or this: https://mail.gnome.org/archives/gtk-list/2011-March/msg00043.html > No need to destroy it. Build the menu, keep a pointer to the built > menu around somewhere, and pop it up when you need it. > > If you close the window you built the menu for, you can destroy the > menu in the window's dispose method. So the leak is basically "expected"? Unless SWT/JFace re-uses menus, or disposes them at *unknown* point in time (end of application life-cycle is not an option...). Though as before I don't know how reliable the information from the links is...
I'm trying to call gtk_widget_destroy() during Menu.releaseWidget(), but that doesn't seem to help. I was checking use of Menu.handle and noticed this code: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT/gtk/org/eclipse/swt/widgets/MenuItem.java#n1080 if (oldMenu != null) { oldMenu.cascade = null; /* * Add a reference to the menu we are about * to replace or GTK will destroy it. */ OS.g_object_ref (oldMenu.handle); GTK3.gtk_menu_item_set_submenu (handle, 0); } This seems to be called during our test, as well as when debugging a snippet via Java editor context menu (right-click in the editor) -> Debug -> Debug as Java application. I did try to add a matching number of g_object_unref() calls to Menu.releaseWidget(), but that doesn't seem to help either. A snippet to run into the g_object_ref() code is e.g.: public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout(SWT.VERTICAL)); for (int j = 0; j < 11; j++) { Menu menu1 = new Menu(shell, SWT.NONE); Menu menu2 = new Menu(shell, SWT.DROP_DOWN); Menu menu3 = new Menu(shell, SWT.DROP_DOWN); MenuItem item = new MenuItem(menu1, SWT.CASCADE); item.setMenu(menu3); item.setMenu(menu2); menu1.dispose(); menu2.dispose(); menu3.dispose(); } shell.open(); while (display.readAndDispatch()) { // process UI events } display.dispose(); } This then runs into the original leak reported here (see the description): [16896 bytes leaked] je_prof_backtrace (/home/sandreev/git/misc/jemalloc/src/prof.c:636 (discriminator 2)) je_malloc_default (/home/sandreev/git/misc/jemalloc/src/jemalloc.c:2289) g_malloc (??:?) g_slice_alloc (??:?) g_slice_alloc0 (??:?) g_type_create_instance (??:?) g_object_unref (??:?) g_object_new_with_properties (??:?) g_object_new (??:?) Java_org_eclipse_swt_internal_gtk3_GTK3_gtk_1menu_1new (??:?) ?? (??:0) I'll continue with looking into this...
Seems to be a GTK bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4018 @Simeon I didn't mean to spend your time in vain. Didn't expect it to be another GTK bug, thought that it's an SWT problem which would be easy to find from reduced snippet.
(In reply to Alexandr Miloslavskiy from comment #11) > Seems to be a GTK bug: > https://gitlab.gnome.org/GNOME/gtk/-/issues/4018 > > @Simeon I didn't mean to spend your time in vain. Didn't expect it to be > another GTK bug, thought that it's an SWT problem which would be easy to > find from reduced snippet. OK, thanks! I've opened: RHEL support case: https://access.redhat.com/support/cases/#/case/02961572 RHEL bugzilla ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1970254 After the problem in GTK+ is fixed (*if*, its fixed...) we can look into this again to see if there are remaining leaks for SWT Menu.
We got a comment on the RHEL bugzilla ticket: > — Comment #5 from Matthias Clasen <mclasen@redhat.com> — We recently took a look at the upstream issue, and we believe that the memory leak will go away if you sink the floating references of the menu objects. > > Ie, instead of > > menu = gtk_menu_new (); > > use > > menu = gtk_menu_new (); > g_object_ref_sink (menu); > > and instead of > > gtk_widget_destroy (menu); > > use > > gtk_widget_destroy (menu); > g_object_unref (menu); I'll see if I can add this to SWT and whether it fixes the leak.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187091
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/187091 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8820141ad6d98ffd32bf5819a3bc1351f3a1757a
Nice job! I have also tested the patch with a tool that detects memory errors (such as use-after-free) on Ubuntu 21.04. It looks good.
