touch-packages team mailing list archive

[Rolf Leggewie <1103050@xxxxxxxxxxxxxxxxxx>]

quantal has seen the end of its life and is no longer receiving any
updates. Marking the quantal task for this ticket as "Won't Fix".

** Changed in: libdbusmenu (Ubuntu Quantal)
       Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libdbusmenu in Ubuntu.
https://bugs.launchpad.net/bugs/1103050

Title:
  Leak in method call handlers for calls that don't require a reply

Status in DBus Menu:
  Fix Released
Status in libdbusmenu package in Ubuntu:
  Fix Released
Status in libdbusmenu source package in Precise:
  Fix Released
Status in libdbusmenu source package in Quantal:
  Won't Fix

Bug description:
  [Impact]

   * Affected applications with a high number of menu updates reach the maximum value allowed for the ID of a menuitem, and rejects further menu changes. Because the application underneath the menu has already removed the underlying actual GtkMenuItem objects, it is impossible to activate the items -- to effect the actions linked to the menuitems.
   * Some indicators and applications have a relatively high and climbing memory usage due to the way they build menus to be displayed in the panel.

  [Test Case]

   * Run nm-applet for a while (multiple days without shutdown, without killing the application), notice whether the menus are still usable.
   * Run indicators for a while, observe memory usage.

  [Regression Potential]

  Indicators with a very high amount of updates may be affected as circling back past the maximum value, if a new menu item is created with an ID still in use by a menuitem that has not been removed yet, neither or only one of the two menu items might be available to be clicked -- this could confuse users or cause error messages to be displayed.
  Risk is low however since network-manager-gnome (nm-applet) is currently the application with the most menu updates.

  [Other Info]
  We get tonnes of these in Firefox:

  ==16593== 16,032 (1,152 direct, 14,880 indirect) bytes in 12 blocks are definitely lost in loss record 8,169 of 8,180
  ==16593==    at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==16593==    by 0xBC83410: g_malloc (gmem.c:159)
  ==16593==    by 0xBC98522: g_slice_alloc (gslice.c:1003)
  ==16593==    by 0xBC98A75: g_slice_alloc0 (gslice.c:1029)
  ==16593==    by 0xBA164A4: g_type_create_instance (gtype.c:1892)
  ==16593==    by 0xB9F9E37: g_object_constructor (gobject.c:1855)
  ==16593==    by 0xB9FB920: g_object_newv (gobject.c:1638)
  ==16593==    by 0xB9FBF6B: g_object_new (gobject.c:1548)
  ==16593==    by 0xDC09C03: _g_dbus_method_invocation_new (gdbusmethodinvocation.c:326)
  ==16593==    by 0xDBF129E: validate_and_maybe_schedule_method_call (gdbusconnection.c:4826)
  ==16593==    by 0xDBF282A: on_worker_message_received (gdbusconnection.c:4890)
  ==16593==    by 0xDC06257: _g_dbus_worker_do_read_cb (gdbusprivate.c:492)
  ==16593==    by 0xDB9EA4D: g_simple_async_result_complete (gsimpleasyncresult.c:777)
  ==16593==    by 0xDB9EB7B: complete_in_idle_cb (gsimpleasyncresult.c:789)
  ==16593==    by 0xBC7D5C4: g_main_context_dispatch (gmain.c:2784)
  ==16593==    by 0xBC7D907: g_main_context_iterate.isra.25 (gmain.c:3359)
  ==16593==    by 0xBC7DD71: g_main_loop_run (gmain.c:3553)
  ==16593==    by 0xDC03D95: gdbus_shared_thread_func (gdbusprivate.c:277)
  ==16593==    by 0xBCA15F4: g_thread_proxy (gthread.c:798)
  ==16593==    by 0x5643F9E: start_thread (pthread_create.c:311)
  ==16593==    by 0x59500CC: clone (clone.S:114)

  Basically, dbusmenu needs to unref the GDBusMethodInvocation in its
  handlers when not sending a reply (ie, not calling one of the
  g_dbus_method_invocation_return_* functions)

  I've got a patch that fixes this already

To manage notifications about this bug go to:
https://bugs.launchpad.net/libdbusmenu/+bug/1103050/+subscriptions