desktop-packages team mailing list archive

[Ubuntu QA's Bug Bot <bug-stats@xxxxxxxxxxxxxxx>]

** Tags added: testcase

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/783997

Title:
  Firefox 4.0.1 Crash Report [@ uGlobalMenuBar::ShouldParentStayVisible
  ]

Status in Unity global menubar extension for Firefox and Thunderbird:
  Fix Released
Status in Global menubar extension 1.0 series:
  Fix Released
Status in “firefox” package in Ubuntu:
  Fix Released
Status in “thunderbird” package in Ubuntu:
  Fix Released
Status in “firefox” source package in Natty:
  Fix Released
Status in “thunderbird” source package in Natty:
  Triaged

Bug description:
  *** TEST CASE FOR SRU ***

  This one is pretty difficult to reproduce, and it doesn't help that we
  have no way of contacting the people who reported the crash reports to
  Mozilla's crash system. However, I have a test case which I think
  triggers the same bug

  Preparation:
  - Install indicator-appmenu-dbgsym

  Test:
  1) Attach gdb to unity-panel-service
  2) Start Firefox or Thunderbird
  3) In gdb, add a breakpoint on register_windows in indicator-appmenu.c
  4) In Firefox, open a new window (or compose an e-mail in Thunderbird)
  5) As soon as the new window appears, close it
  6) gdb should have stopped on register_windows. Type cont so that Firefox (or Thunderbird) gets the reply

  Result:
  - With the old version, Firefox (or Thunderbird) will crash occasionally. It won't happen everytime (it might take several attempts to make it crash), and the trace may not look exactly the same as the ones linked from this bug, but I'm pretty sure it's the same issue (having uGlobalMenuBar::SetXULMenuVisibility in the trace is key). The issue is that all the members of the uGlobalMenuBar instance are invalid (as it was destroyed when the window was closed), so it could crash anywhere inside uGlobalMenuBar::SetXULMenuVisibility really.
  - With the new version, they won't ever crash

  ***

  There's lots of crash reports like this:

  https://crash-
  stats.mozilla.com/report/list?product=Firefox&platform=linux&query_search=signature&query_type=contains&query=uGlobalMenu&reason_type=contains&date=05%2F17%2F2011%2003%3A58%3A09&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=uGlobalMenuBar%3A%3AShouldParentStayVisible

  This is crashing where we iterate over the menubar's parent nodes to
  figure out which node we should hide. The issue here is that we hold a
  ref on the menubar, but each node doesn't hold a ref to its parent
  (else there would be reference cycles). The code sort-of makes an
  assumption that the pointer returned from GetParent() isn't dangling,
  but it looks like it's hitting a case where it is.

  I'm not sure what condition would cause this yet. One possibility is
  that the window is being closed (and the document being destroyed) in
  between calling RegisterWindow and getting a response back from the
  panel service (which is when this code path gets triggered). In this
  condition though, it would be unsafe to access any uGlobalMenuBar
  functions for the particular menubar, as the menuservice would have
  already destroyed it

To manage notifications about this bug go to:
https://bugs.launchpad.net/globalmenu-extension/+bug/783997/+subscriptions