Intermittent browser_blocklist.js | sub-test testBlockingExistingProvider failed: Error: SocialService.addProvider: provider with this origin already exists | browser_social_multiprovider.js | correct number of providers listed in the menu and a leak

RESOLVED FIXED in Firefox 24

Status

defect
RESOLVED FIXED
7 years ago
6 months ago

People

(Reporter: RyanVM, Assigned: scaraveo)

Tracking

({intermittent-failure, memory-leak})

Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox24 fixed, firefox25 fixed, firefox26 fixed)

Details

Attachments

(1 attachment)

https://tbpl.mozilla.org/php/getParsedLog.php?id=20233574&tree=Mozilla-Inbound

Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound debug test mochitest-browser-chrome on 2013-03-01 13:44:36 PST for push 23d0ee5b4483
slave: talos-r4-snow-053

13:53:56  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/social/browser_blocklist.js | sub-test testBlockingExistingProvider failed: Error: SocialService.addProvider: provider with this origin already exists
13:54:32  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/social/browser_social_multiprovider.js | correct number of providers listed in the menu - Got 3, expected 2
15:03:11  WARNING -  TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 5903957 bytes during test execution
15:03:11  WARNING -  TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 2 instances of AsyncStatement with size 88 bytes each (176 bytes total)
15:03:11  WARNING -  TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 2000 instances of AtomImpl with size 40 bytes each (80000 bytes total)
15:03:11  WARNING -  TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of BackstagePass with size 48 bytes
15:03:11  WARNING -  TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of BodyRule with size 32 bytes
15:03:11  WARNING -  TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of CalculateFrecencyFunction with size 24 bytes

The leak analyzer says that 6 DOMWindows were leaked.
FWIW, the failure in comment 2 appears to be a different (and even more confounding) orange in browser_social_activation.
Depends on: 886300
Shane, any more ideas on this?
Flags: needinfo?(mixedpuppy)
Between this bug, bug 886300 and bug 846600 I did see some things via the logs that I am fixing.  I'm not certain they are the ultimate cause, but they do clean up a couple situations that fix some potential intermittent failures.

https://tbpl.mozilla.org/?tree=Try&rev=2cc3b1f3b0ca
Flags: needinfo?(mixedpuppy)
This should fix some stuff I saw in logs throughout the blocklist bugs (this, 886300, 846600).  I say "should", since I'm unable to repro via try with the patch.  In the least, it doesn't break anything (see above try) :)  Some of these changes were necessary anyway (e.g. uninstall callback) in some of the new work going on in bug 891225 and bug 891219.

stuff I saw in logs:
- provider from browser_addons.js leaked past the end of testing in that file (I was able to repro this one locally)
- window watcher from browser_blocklist leaked into a much later test
- blocklist cleanup not actually cleaning up, the simplifies by just resetting the blocklist rather than using an "empty" blocklist file.
Attachment #795520 - Flags: review?(mhammond)
Comment on attachment 795520 [details] [diff] [review]
fix intermittent failure

Review of attachment 795520 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/test/social/browser_blocklist.js
@@ +134,5 @@
> +        let domwindow = aXULWindow.QueryInterface(Ci.nsIInterfaceRequestor)
> +                                  .getInterface(Ci.nsIDOMWindow);
> +
> +        domwindow.addEventListener("unload", function _unload() {
> +          domwindow.removeEventListener("unload", _unload);

missing 3rd param of false here

@@ +158,3 @@
>          // the act of blocking should cause a 'provider-removed' notification
>          // from SocialService.
> +        SocialService.registerProviderListener(function providerListener(topic) {

is it possible the order of these might cause orange?  ie, that the provider-removed notification might come before the addProvider callback has fired?
Attachment #795520 - Flags: review?(mhammond) → review+
(In reply to Mark Hammond (:markh) from comment #40)
> Comment on attachment 795520 [details] [diff] [review]

> @@ +158,3 @@
> >          // the act of blocking should cause a 'provider-removed' notification
> >          // from SocialService.
> > +        SocialService.registerProviderListener(function providerListener(topic) {
> 
> is it possible the order of these might cause orange?  ie, that the
> provider-removed notification might come before the addProvider callback has
> fired?

no, we set the blocklist inside the addProvider callback, after registering the listener.
https://hg.mozilla.org/mozilla-central/rev/b8217f322b54
Assignee: nobody → scaraveo
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 26
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.