Firefox 4.0.1 Crash Report [@ uGlobalMenuBar::ShouldParentStayVisible ]

[Chris Coulson]

*** 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

[Martin Pitt (pitti)]

Accepted firefox into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 5.0~b2+build1+nobinonly-0ubuntu1

---------------
firefox (5.0~b2+build1+nobinonly-0ubuntu1) oneiric; urgency=low

  * New upstream release from the beta channel (FIREFOX_5_0b2_BUILD1)
    - Fixes LP: #765970

  * Switch to mozilla-beta
    - update debian/mozclient/firefox.conf
  * Drop support for building with an external xulrunner
    - update debian/apport/firefox.in
    - update debian/firefox.install.in
    - update debian/firefox.lintian-overrides.in
    - update debian/firefox.sh.in
    - update debian/mozconfig.in
    - update debian/rules
  * Ditch all the version-number based branding selection. Do this all
    purely on the channel name now
    - remove debian/firefox-beta.desktop.in
    - remove debian/firefox-nightly.desktop.in
    - remove debian/firefox-unofficial.desktop.in
    - rename debian/firefox-final.desktop.in => debian/firefox.desktop.in
    - update debian/firefox.desktop.in
    - update debian/rules
    - update debian/firefox.sh.in
  * Drop the DEB_ENABLE_IPC option, now that IPC is mandatory
    - update debian/rules
    - update debian/apport/firefox.in
    - update debian/firefox.install.in
    - update debian/mozconfig.in
  * Build language packs directly from the firefox source
    + Fixes LP: #294187 - Firefox Locales should install locale specific
      search plugins
    + Rip out the bits to create a en-US.xpi
      - update debian/rules
      - remove debian/translation-support/install.rdf.in
    + Include compare-locales FIREFOX_5_0b1_BUILD1 from
      http://hg.mozilla.org/build/compare-locales. It's needed for merging
      en-US strings with incomplete locales
    + Pull l10n data in to tarball from bzr
      - update debian/mozclient/firefox.conf
    + Configure build for creating language packs by configuring with
      "--with-l10n-base="
      - update debian/mozconfig.in
    + Store the list of locales to ship, and provide a way of automatically
      generating that list and the control file entries from the upstream
      source. Also provide a way to blacklist languages. We map languages
      to package names using langpack-o-matic (and also get descriptions
      from there too)
      - update debian/rules
      - add debian/locales-supported
      - add debian/control.langpacks
      - update debian/control
      - add debian/locale-blacklist
      - add debian/refresh-supported-locales.pl
    + Add common-build-indep hook to build the translation xpi's
      - update debian/rules
    + Add common-binary-post-install-indep to install the xpi's and
      searchplugins in to the correct debian packages
      - update debian/rules
      - add debian/get-xpi-id.py
    + When rebuilding debian/control in the clean target, fail the build
      if the control file was out-of-date. This ensures that we don't
      accidentally drop language packs, and forces me to maintain an
      up-to-date control file in bzr
      - update debian/rules
    + Apply vendor patches to localized searchplugins too
      - update debian/patches/ubuntu-codes-amazon.patch
      - add debian/patches/ubuntu-codes-baidu.patch
      - update debian/patches/ubuntu-codes-google.p...

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 4.0.1+build1+nobinonly-0ubuntu0.11.04.3

---------------
firefox (4.0.1+build1+nobinonly-0ubuntu0.11.04.3) natty-proposed; urgency=low

  * Update globalmenu-extension to 1.0.5:
  * Fix LP: #783790 - Firefox 4 crashes when opening Selenium IDE window.
    Ignore signals for menus without popups
  * Fix LP: #783856 - Firefox 4.0.1 Crash Report
    [@ uGlobalMenuBar::~uGlobalMenuBar ]. Don't bail out of building a menu
    when encountering a non-XUL element. Also toughen up destructors to not
    crash if the menuitem never initialized properly
  * Fix LP: #783997 - Firefox 4.0.1 Crash Report
    [@ uGlobalMenuBar::ShouldParentStayVisible ]. Don't crash if the window
    gets destroyed before the panel responds to RegisterWindow
 -- Chris Coulson <email address hidden> Tue, 17 May 2011 18:28:28 +0100

[Rolf Leggewie (r0lf)]

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