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".
** Changed in: thunderbird (Ubuntu Natty)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Unity API
bugs, which is subscribed to Global menubar extension.
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:
Won't Fix
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
--
Mailing list: https://launchpad.net/~unity-api-bugs
Post to : unity-api-bugs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~unity-api-bugs
More help : https://help.launchpad.net/ListHelp
