The version of appmenu-gtk in the proposed pocket of Precise that was
purported to fix this bug report has been removed because the bugs that
were to be fixed by the upload were not verified in a timely (105 days)
fashion.
** Changed in: appmenu-gtk (Ubuntu Precise)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of DX
Packages, which is subscribed to appmenu-gtk in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/787736
Title:
RebuildData structs are leaked in rebuild() / do_rebuild()
Status in AppMenu GTK+:
Fix Released
Status in appmenu-gtk package in Ubuntu:
Fix Released
Status in appmenu-gtk source package in Precise:
Won't Fix
Bug description:
[Impact]
This issue affects most and any users of appgtk-menu, such as nm-applet,
especially in environments (such as offices) where the detected wireless
networks change a lot, and where roaming can occur frequently. See also: LP:
#780602
[Test Case]
Run nm-applet for multiple hours:
- Observe that the VPN Connections submenu still opens and lists connections
(if VPN connections are configured)
- Observe that the "More networks" submenu for additional detected wireless
networks still opens and lists networks.
A common failure case is where such a submenu will open but show an
empty list (a piece of menu a few milimeters long).
[Regression Potential]
Minimal, the fixes have been available for a while in the development release
(and in other recent releases) with no regressions.
Possible issues could be introducing new memory leaks with the changes
however, and although the risk is minimal, this could cause the same failure
behavior as listed above under [Test Case].
--
Binary package hint: appmenu-gtk
The rebuild function creates a hash table mapping the toplevel to the
g_timeout id responsible for doing the refresh.
The rebuild function allocates a RebuildData object to pass to the
do_rebuild idle function. The do_rebuild callback function frees this
object when it is called.
However, the do_rebuild function isn't guaranteed to be called. In
fact the whole point of the hash table seems to be that the callback
can be canceled. When that happens, the RebuildData object isn't
freed, causing a leak.
Additionally, instead of storing a proper reference to the toplevel in
the RebuldData object, a weak pointer is stored instead. But if the
weak pointer gets set to null, the do_rebuld function will lose its
only copy of that pointer, so it will have no way of cleaning up the
associated entry in the hash table.
To manage notifications about this bug go to:
https://bugs.launchpad.net/appmenu-gtk/+bug/787736/+subscriptions
--
Mailing list: https://launchpad.net/~dx-packages
Post to : dx-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dx-packages
More help : https://help.launchpad.net/ListHelp
