LeechBlock doesn't get along well with Firefox's GC

[benburrill]

I've been having memory issues for a while now where Firefox's memory usage steadily rises (a couple MB/s), sometimes falling back on its own, but disturbingly often it just keeps on rising seemingly forever. Disabling LeechBlock stops the memory from rising.

To deal with this, whenever my computer starts getting slow, I go to about:memory, clear the GC, and then turn swap on and off again. This is annoying, but it's better for my productivity than disabling LeechBlock!

When measuring memory in about:memory, the problem shows up as structured-clone-holder and I think the problem is likely related to this Firefox issue. Specificially, I believe this problem is because LeechBlock sends messages to tabs every second to update the time remaining, creating those structured-clone-holders at such a frequency that Firefox's GC can't keep up. However, I don't really see why the background script needs to be responsible for the countdown. The tabs can maintain their own timer which can be updated by the background script whenever you switch to the tab, but for the most part the tabs can just do the count-down on their own.

I'm using Firefox 70 on Linux.

[martinxyz]

Just to confirm, this is a problem for me, too.

With a couple of tabs open, I'm measuring a growth of ~7MB per minute of the "WebExtensions" process. Firefox is just sitting in the background. Disabling LeechBlockNG stops the leak. (Measured without restarting Firefox. Firefox 71 on Linux. With some other extensions also running.)

[benburrill]

The workaround I've settled on is turning on the "Process only active tabs" setting. This completely (or at least to the extent that I can notice) fixes the problem. However, depending on your block settings, this may not be the behavior you want. I somewhat recently changed my block settings to be entirely delay-based, and "Process only active tabs" works flawlessly with that since there is no need to update any other tabs.

Of course the issue still exists and needs to be fixed, but for my purposes LeechBlock thankfully works sensibly again.

[martinxyz]

Great workaround, thank you. I've also settled on delay-based blocking long ago. At first it felt like cheating to get around the block just by standing up and doing some quick other task. Until I realized what a positive change this was :-)

[proginosko]

I wonder if this is a Linux-specific issue. I'm using FF on Win10 and I haven't encountered any LB memory-usage issues. Even with a lot of tabs open, LB usage remains constant at around 550KB.

[benburrill]

Yeah, I figure it is Linux-specific. The Firefox issue I linked was also reported by a Linux user. I have not tried to reproduce on another OS though.

[martinxyz]

More testing:

• I can reliably reproduce memory growth of 0.5MB/s with ~20 tabs. But in some test cases the growth is not permanent, e.g. with a fresh Firefox profile it jumps back every ~10 seconds.
• I can reproduce this with an empty LeechBlockNG config. (No blocking configured. Loaded as a temporary extension, git master 4075ff, with a new manifest-gecko-id.)

Code exploration:

• background.js never calls browser.tabs.sendMessage() while I'm viewing about:debugging, yet memory grows.
• Even with an empty config there is a lot of code running for every second { for each tab { for all 6 sets { ... }}}. Much is skipped by not passing testURL(), but still this seems excessive when Firefox is in the background. This polling is using about 0.5% of my CPU, probably much more if most tabs are in a block-set. Sadly the profiler doesn't show any details.
• IMO processing only the active tab(s) is a good-enough solution. I don't see the point of doing anything with hidden tabs until they become active. But I'm not familiar with all use-cases. My habit is to accumulate hidden tabs as a sort-of weekly reading list.

[rakyi]

I'm seeing this issue in Firefox 132.0.2 on macOS 15.1, but I observed it also in the past on older versions. I usually have at least a few dozen tabs open across 1–3 windows.