1741860 - Extensions process is leaky, explodes even more with "Measure" command in "about:memory"

Status: RESOLVED INCOMPLETE

(Toolkit :: about:memory, defect, P3)

Description

[User Dderss]

Attachment: Безымянный1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Just regular browsing with lots of video (YouTube) playback.

Actual results:

1. Extension process blows up into huge gigabytes, dozens of them in heap allocation.
2. And, what is worse, is that at times it can not be even "measured" with the corresponding command in "about:memory": the page just keeps showing "Measuring..." status forever. Reloading the page does not help.
3. Even yet worse is that at times the extension process blows up even much crazier once you click on "Measure" command quickly consuming all possible Windows swap file memory until it all crashes.

A probable candidate for #1 is "Undo Closed Tabs" extension but replacing it with "Undo Closed Tab Button" alternative extension did not help. However, regardless of which extensions do what in no way "Measure" command should cause #2 and #3 effects. This bug about not the former but the LATTER.

Expected results:

Normal continuous operation.

Comment 1

[User Dderss]

Attachment: Безымянный2.png

Comment 2

[User Dderss]

Attachment: Безымянный3.png

Comment 3

[User Dderss]

Killing the extension process, of course, immediately helps but, unfortunately, FF does not have a watcher process to: 1) check for memory leaks in working processes (as in this bug report) 2) (re-)start processes that have crashed or were killed.

This feature was requested for years but so far it was not implemented. Does anyone know how to force FF to (re-)start the extension process without relaunching the whole thing?

Thanks in advance.

Comment 4

[User Dderss]

After more tests, both extensions that undo closed tabs are now eliminated from the possible culprits.

Now am testing for PocketTube.

Comment 5

[Alex Cornestean]

Hello,

I’ve attempted to reproduce the issue on the latest Beta (95.0b10/20211121185651) under Windows 10 x64, using several of the add-ons you listed in Comment 2 which I considered to have an involvement with YouTube – Autoplay No More and PocketTube.

No unusual memory usage was observed using these add-ons.

I also observed you are using Tampermonkey. Can, by any chance, a custom script you are using be causing this leakage?

Comment 6

[User Dderss]

After more testing, PocketTube seems to be also eliminated from the list of culprits.

Yes, Tampermonkey has some scripts running and this is the main possible culprit currently. Not sure if this is exactly the scripts are the issue since they did not change for a long time already. So for now I have replaced TamperMonkey with ViolentMonkey to see if the memory will explode or not.

However, as I mentioned in the very first post of this thread, my main issue is not the leak itself but the fact that the "Measure" command can not deal with leaky, corrupted extension process and sometimes not only fails to work but also makes things even much worse: it adds more than a gigabyte of memory use every second during this.

There HAVE to be integrity checks along with the command so it would be impossible for it to fail let alone to crash the whole thing due to some Super Sayan level of the explosion of the memory. (And I am still wondering why there is no watcher process as a general solution to leaky processes.)

Comment 7

[Rob Wu [:robwu]]

Could you describe your issue more clearly?

According to comment 5 the leak cannot be reproduced.

According to comment 6, the complaint is that the Measure button doesn't work as intended. I can imagine that measuring the usage requires reading (swapped-out) memory, which in turn could result in (slow) swapping. That doesn't sound too unexpected.

Comment 8

[User Dderss]

Alas, I can not describe the issue any more clearly than I already did in the root post. It is very simple: just browsing the Internet as usual for some time and then at some point the memory is all of a sudden starting to explode. It is not a simple case when you start a browser and then do an exact specific thing that triggers the OOM disaster.

The complaint is actually right in the root post, not in comment 6 (it just stresses it out again). The behaviours described in #2 and #3 points of the root post are not expected as even during memory blowout as described in #1 normally it is perfectly measurable (as demonstrated in one of the screenshots) by the "Measure" command, there are zero issues with swapping or whatever else.

Under no circumstances, behaviours #2 and #3 are expected. And this is the bug's whole issue, not finding what is causing the blowing up in the first place, which is secondary.

Comment 9

[Rob Wu [:robwu]]

Thanks for clarifying. Since you're not interested in the cause of the leak in the extension process, but really about about:memory being unusable, I'll move this bug report to the component of about:memory for further triage.

Comment 10

[User Dderss]

Thanks.

So far on the secondary issue, it looks like it is a specific extension problem so there is nothing much Mozilla staff should or even can do about unlike e. g. how the memory measurement system works when trying to measure the memory of (or to enumerate objects in) corrupted, leaky processes regardless of whether it is the extensions process or whichever else process that be.

Comment 11

[Rob Wu [:robwu]]

(In reply to User Dderss from comment #10)

Thanks.

So far on the secondary issue, it looks like it is a specific extension problem so there is nothing much Mozilla staff should or even can do about

Sometimes a leak in an extension is caused by the extension framework in Firefox rather than extension-specific. If in doubt and you have a reliable way to reproduce the issue, feel free to file a new bug in the WebExtensions::General component.

Comment 12

[User Dderss]

Indeed, this could be the case, too, though maybe not that likely in this time.

The current suspect for the initial memory blowout, Tampermonkey, does not show any explicit storage size explosion right during the memory issue: I have checked the two scripts that have the storage privilege and in both cases they were fine, nothing was corrupted or huge there. So it is not like some script is written too poorly and all of a sudden enters an endless cycle of adding garbage to the storage. And yet once I turned the Tampermonkey extension off, the huge memory use in the extension process was gone.

This could make one think that it might be a framework problem but the initial memory explosion issue so far has not happened to me after replacing Tampermonkey with Violentmonkey even though the scripts are exactly the same. But, of course, I will test it more; if the issue will appear on ViolentMonkey, too, I will follow your advice about filing a separate bug on this; thanks again.

Comment 13

[Henri Sivonen (:hsivonen)]

Setting severity to S3 on the logic that about:memory isn't a feature that users typically use. needinfoing mccr8 for a second opinion.

Comment 14

[Andrew McCreight [:mccr8]]

Does about:memory work any better if you have the anonymize checkbox selected? That can help because it disables the string duplication checking.

But yeah, generally it is a known issue that if a process has a gigantic leak that memory reporting won't work very well. I'm not sure if there are any great solutions. There's supposed to be a timeout so it won't hang forever, so I'm not sure why that isn't working. On the other hand, this means it doesn't indicate anywhere when a process fails to respond.

If indeed it is string duplication that is causing the issues, maybe we need to skip that step if there are too many.

Comment 15

[User Dderss]

Thanks, Andrew. I will try to use Anonymize option next time to see how well it is going.

However, the issue is that:

-- in the #2 effect where "Measuring..." is shown forever the browser does not seem to do anything, none of FF processes become any busier than usual when no actual measuring is happening -- unlike cases where the command actually works;

-- in the #3 effect where the Measure command causes already huge extension process to grow by like a gigabyte per second (!) is catastrophic and unrecoverable without either killing the extension process or the browser itself (or this will happen anyway via OOM crash once Windows swap file reaches 100 GB or something like that, which is the limit in my boot drive).

In the former, the Anonymize option will not likely make a difference and the latter I will have no chance to use it or I will not understand if it is working or not since the explosive leak on Measure command does not happen every time.

I guess that in both cases the measuring fails because of corruption of objects in the extension process which in one case makes the operation quit, hence not reaching the timeout code, though not completely, it is maybe left hanging in some "await" somewhere so it always left with "Measuring..." shown, and in another, it maybe enters some infinite enumeration feedback loop due to maybe self-reference corruption

Can the two cases be taken into account in the code of the "Measure" command?

Comment 16

[Andrew McCreight [:mccr8]]

Not really enough to go on here.