Closed Bug 679675 Opened 13 years ago Closed 13 years ago

Zombie compartment with techspot.com and particular Adblock Plus filters

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 672111

People

(Reporter: emorley, Unassigned)

References

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 file)

Attached file Reduced filterset
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110816 Firefox/8.0a1

1) Create a clean profile.
2) Install AdblockPlus [1], restart Firefox, cancel the offer to add subscriptions.
3) Import the filters [2] attached to this bug (Addons toolbar -> adblock icon -> preferences -> Filters menu -> import filters -> overwrite).
4) Restart Firefox.
5) Open http://www.techspot.com in one tab, about:memory?verbose in another; no other tabs open.
6) Close the techspot tab.
7) Press minimise memory usage in about:memory several times / wait a few minutes.
8) Observe compartments remaining in about:memory.

Expected:
No techspot.com compartment left.

Actual:
Approx 80% of the time [3], a zombie compartment remains.

│  ├───1,422,785 B (04.20%) -- compartment(http://www.techspot.com/)
│  │   ├────454,656 B (01.34%) -- gc-heap
│  │   │    ├──224,792 B (00.66%) -- arena-unused
│  │   │    ├──138,176 B (00.41%) -- objects
│  │   │    ├───83,880 B (00.25%) -- shapes
│  │   │    ├────4,528 B (00.01%) -- strings
│  │   │    ├────1,776 B (00.01%) -- arena-headers
│  │   │    └────1,504 B (00.00%) -- arena-padding
│  │   ├────327,680 B (00.97%) -- mjit-code
│  │   ├────203,696 B (00.60%) -- tjit-data
│  │   │    ├──100,464 B (00.30%) -- trace-monitor
│  │   │    ├───74,000 B (00.22%) -- allocators-reserve
│  │   │    └───29,232 B (00.09%) -- allocators-main
│  │   ├────164,999 B (00.49%) -- scripts
│  │   ├────131,072 B (00.39%) -- tjit-code
│  │   ├─────75,000 B (00.22%) -- mjit-data
│  │   ├─────40,392 B (00.12%) -- property-tables
│  │   ├─────15,304 B (00.05%) -- object-slots
│  │   └──────9,986 B (00.03%) -- string-chars



[1] I'm using Adblock Plus dev v1.3.10a.3121 (current latest dev version), in case it makes a difference in the future, you can find that exact build in the archive here: https://adblockplus.org/devbuilds/adblockplus/

[2] The filterset in the attached file was obtained by installing the three Fanboy ABP subscription lists (Adblock, Tracking & Annoyance) on this page: http://www.fanboy.co.nz/ - and then reducing down until the problematic filters were found. Attaching as a file in case when the subscriptions update, those specific filters no longer exist.

[3] I'm not sure what causes it to correctly disappear in the 20% of cases, but perhaps related to ad-rotations / whether the page was interacted with (eg rolling over the JS site navigation tabs) / gremlins. If the compartment doesn't persist, open techspot again in a new tab (I've found undo close tab doesn't seem to help in these cases, perhaps confirming the ad rotation theory).
I tried to follow the steps but I cannot reproduce the issue (identical Firefox and Windows version). I can see a zombie compartment if I press Ctrl-Shift-V to open the list of blockable items in Adblock Plus - but that's apparently the case for every website and independent of any filters, so likely a different issue (will need to look into this). If this is really dependent on the ads being displayed, reproducing will be hard because these ads are likely dependent on your location.
On some of the test runs I did indeed have the blockable items panel open (which would explain those cases), but for the majority I did not. However I think you may be right that this is hard to reproduce due to ads presumably differing by location / being rotated in general :-( Thanks for trying out the steps in comment 0 anyway, sorry it wasn't more successful! :-)

As for the blockable items zombie compartment, do you wish me to file a bug somewhere for that, or is that not necessary?
(In reply to Ed Morley [:edmorley] from comment #2)
> As for the blockable items zombie compartment, do you wish me to file a bug
> somewhere for that, or is that not necessary?

I already have that on my to-do list, I will file a bug once I've isolated the cause (might also be something that needs to be fixed on my side).
Ed, thanks for the detailed and precise steps-to-reproduce.  ABP has been implicated in some other zombie compartment cases (e.g. bug 677212).  If it's location-dependent, that would explain why it seems to be a problem for some people but not others (e.g. me).
The adblock plus related zombies are a bit difficult to consistently reproduce.  I am, however, able to reproduce the comment 0 case.

One interesting thing about this issue is this:  If you have a zombie compartment as a result of this bug, disabling the offending filter (or disabling adblock plus) and revisiting the site will result in that zombie compartment being destroyed the next time the tab is closed.
Target Milestone: --- → mozilla8
Version: Trunk → Other Branch
Target Milestone: mozilla8 → ---
Version: Other Branch → Trunk
(In reply to Wladimir Palant from comment #1)
> I can see a zombie compartment if I press
> Ctrl-Shift-V to open the list of blockable items in Adblock Plus - but
> that's apparently the case for every website and independent of any filters,
> so likely a different issue (will need to look into this).

After some investigation the reason turned out to be my nsITreeView implementation holding references to some DOM nodes. This delayed garbage collection of the compartment even though the document containing the <tree> element has been unloaded. Detaching the tree view from the tree explicitly made this issue go away (https://hg.adblockplus.org/adblockplus/rev/98cb429a6082). Not a bug I guess?
(In reply to Wladimir Palant from comment #6)
> Detaching the tree view from the tree explicitly
> made this issue go away
> (https://hg.adblockplus.org/adblockplus/rev/98cb429a6082). Not a bug I guess?

Sorry, I don't follow.  Did you make a change to ABP that fixes the problem?
I believe Wladimir was referring to the "so likely a different issue" additional bug found in comment 1, rather than the STR in comment 0 (since he was unable to reproduce my original problem). Here's to hoping that the problem found in bug 672111 comment 5 might also solve this :-)
I guess that the problem in bug 672111 comment 5 is causing this issue as well. Since I cannot reproduce it, here is how you can verify that it is the same issue.

1. Once you see the techspot.com zombie compartment in about:memory please open a new (blank) tab.
2. Press Ctrl-Shift-K to open web console.
3. Enter "new Image().src = 'http://example.com/';" into the command line (without the quotation marks) and press Enter.
4. Press Ctrl-Shift-K to close web console again and close this tab.
5. Click "Minimize memory usage" in about:memory again.

These steps trigger a new content policy call for Adblock Plus to process. If the zombie compartment is gone after that then this is the same issue as bug 672111.
(In reply to Wladimir Palant from comment #9)

I was able to confirm that steps 1 to 4 cause the zombie compartment to immediately disappear.  I actually didn't have to do step 5.
Whiteboard: [MemShrink] → [MemShrink:P2]
Wladimir:  Sorry, I'm confused about the status/progress of this bug.  AIUI, ABP has two problems:

(1) Its nsITreeView implementation holds references to some DOM nodes (comment 6 above).  It sounds like this has been fixed by https://hg.adblockplus.org/adblockplus/rev/98cb429a6082?

(2) The redirection detection problem described in bug 672111 comment 5, which is a Firefox architectural problem.

Assuming that's right, perhaps we should re-title this bug to be about (1) -- even though the steps-to-reproduce in comment 0 trigger problem (2) -- and mark it as resolved, and re-title bug 672111 to be about the redirection problem?  Or we could file a new bug for each of (1) and (2) and mark the existing bugs as dups of them, if that would make things clearer?
Nicholas, you are correct. However, the issue reported here is (2), the other issue is only something that I noticed while looking into it. Filing a bug for (1) isn't worth it given that it was an Adblock Plus issue and has been resolved already. So I think that this should simply be marked as a duplicate of bug 672111 (reproducing bug 672111 is easier and judging by comment 10 the issues have the same cause).
(In reply to Wladimir Palant from comment #12)
>
> Filing a
> bug for (1) isn't worth it given that it was an Adblock Plus issue and has
> been resolved already.

Ok.  Can you tell me how big a problem it was?  How often did it occur?

> So I think that this should simply be marked as a
> duplicate of bug 672111 (reproducing bug 672111 is easier and judging by
> comment 10 the issues have the same cause).

Done!  And I retitled bug 672111.  Thanks.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
(In reply to Nicholas Nethercote [:njn] from comment #13)
> Ok.  Can you tell me how big a problem it was?  How often did it occur?

Every time a user opened the list of blockable items in Adblock Plus - which means "not often" because most users don't use that UI. The fix is available in the development builds right now (https://adblockplus.org/en/development-builds) and will be part of the next release.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: