Previously, the lifecycle of popup menus was that you created one with gtk_menu_new(), populated it, and showed it with gtk_menu_popup(); the menu would get destroyed automatically after it was deactivated.

However, since now menus should (or, for GMenu based ones, *must*) be attached to a widget with gtk_menu_attach_to_widget(), the widget it's attached to takes a strong ref to the menu, so the menu is only destroyed once either detached from the widget, or the widget is destroyed. 

Thus, when you create a new popup menu for each context event (which is usual if you're building them custom to the actual context), the old menus build up on the attach widget, and are all destroyed together only when that widget is finally destroyed.

While the latter part is documented in the docs for gtk_menu_attach_to_widget(), it should make it clearer that the menu will *only* be destroyed at that time, not automatically when deactivated, and also the docs for gtk_menu_popup() (and gtk_popup_popup_at_*()) should mention this, and also document a way to avoid this buildup.

The way to manually avoid this buildup is to detach the widget from the attach widget once the menu is deactivated. The complication here is that you *cannot* do this in the 'deactivate' signal handler (which would appear to be the obvious place) because then the action you clicked in the menu will not be actually activated. Instead, you must use the 'selection-done' signal to detach the menu.
 
(Alternatively, menus should do that automatically, ie. when they're attached to a widget, the menu unattach itself on selection-done. That might be considered an ABI change, however.)