CPU pegged at 100%, deeply nested imgLoader::SupportImageWithMimeType

RESOLVED INCOMPLETE

Status

()

Firefox
Untriaged
RESOLVED INCOMPLETE
4 years ago
3 years ago

People

(Reporter: Yet another web site registration, Unassigned)

Tracking

26 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8364019 [details]
Sample of Firefox.txt

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

Start Firefox with my very large saved session (probably a hundred or so open tabs.)

Wait a few minutes.

CPU (one of the cores of my machine) pegs at 100% FOREVER.

Firefox becomes hugely unresponsive.

Memory doesn't seem to be a problem: FF using less than 1gb on a 16gb machine with 6gb free as reported by the OS.

Go back to using Safari, again.  Sigh.

Firefox 26.0, MacOS 10.6.8.



Actual results:

It takes over a second to echo each character I am typing in this text box.
Laptop fan runs continuously.

MacOS "Activity Monitor" application backtrace sample
shows 120+ deep nested calls to imgLoader::SupportImageWithMimeType

mac_plugin_interposing_child_OnShowCursor often might be implicated somehow

Beats me.

Normal complement of unthreatening extensions (Adblock, Cookie Montster, Stylish, DOM Inspector, etc.)

Normal-ish set of MacOS plugins (Flash crapware; Adobe PDF 11.0.6; a couple others.)

Basically, this shouldn't be happening.  But is happening every time for me.


Expected results:

Idle CPU.  Zero Firefox CPU use when idle.

Updated

4 years ago
Whiteboard: [MemShrink]
Can you temporarily disable your add-ons (or try a clean profile... though then you won't have the 100 or so tabs open) to determine if one of them is at fault? When multiple add-ons are present, it's common that one of them is at afult.

Failing that, can you narrow it down to a particular web page?

I realize I'm asking you to do some work here, and that's a pain for you. But for us to even diagnose the problem we need steps to reproduce it.
Whiteboard: [MemShrink]
(Reporter)

Comment 2

4 years ago
Hey thanks for the reply.

I don't mean to sound too ungrateful, but just from a user perspective, the prospect of spending 10 to 20 hours doing "binary search" on my browser history and AND extensions is pretty daunting, and likely totally unrewarding.

The saved session last (recovered from a couple years ago, when I last gave up on Firefox because it used so much idle CPU time running timers to display animated GIFs and other junk on windows and tabs and viewports that weren't has 11 windows and 167 tabs (if I've parsed the sessionstore.js properly which I might not have.)

If there were some automated program I could run which tried to narrow this down, I might run it, but even that would take forever since it takes FF a couple minutes to start up even on my 16gb multi-core laptop "supercomputer" from 2011.

Frankly it seems easier to forget about it and maybe try again in 2017 to see if FF works yet.

AThe business with "Profiles" and disabling stuff and trying to narrow things down: I'm just a user, NOT a developer, and I have no clue.  (Finding "~/Library/Application Support/Firefox/Profiles/HEXRANDOMNESS.default/sessionstore.js" was kind of a big deal and about as far as I can go.)
Also, my browser history and state if moderately valuable to me, so doing experiments with Firefox seems sounds as likely as not to blow away years of, for example, hand-crafted Adblock rules.

If there were some really simple fool-proof user-end-oriented way to do experiments then maybe, but I don't see it.


Bottom line: I hope somebody can extract some value from the TOTALLY CRAZY backtrace with with 585 deeply nested calls to imgLoader::SupportImageWithMimeType.  That really seems like something that code inspection could reveal.


Happy to help to try to find and fix this, but not if it takes 10 or 20 or 100 hours to do so.
(Reporter)

Comment 4

3 years ago
Hi,

This keeps happening to me.

"Big old profiles" was never the case, of course.  And even if it were the case, Firefox shouldn't hang.

Two points of interest:

1. I've seen it happen with a pretty vanilla Firefox configuration running as a Guest account with little ad-on action.  (I'm never going to use any browser without Adblock and without better cookie rejection, so even a plain from-scratch guest account won't run unmodified Firefox.)

2. IT HAPPENS WITH THUNDERBIRD ALSO.  Pretty regularly.  Most recently today with TB 31.1.0.
So it is some sort of common Mozilla framework code, and it has (OF COURSE!) nothing to do with my "big old profile", or with any sort of Firefox profile.




The common thing is backtraces is always
mac_plugin_interposing_child_OnShowCursor
(imgLoader::SupportImageWithMimeType may perhaps be some sort of red herring.)

DumpCompleteHeap and JSD_GetValueForObject often seem to play starring roles as well.

But the hanging backtraces always show at least one nested level of mac_plugin_interposing_child_OnShowCursor

Ideally I'd change the title of this bug, but I don't see how to do that.




PURE SPECULATION: The bug MAY have something to do with "User Switching" on MacOS,
as at least the last couple times this has happened I had changed from my regular
account (using Thunderbird) to a test account and back (perhaps more than once)
and then found that Thunderbird had hung indefinitely in a semaphore wait inside
several levels of mac_plugin_interposing_child_OnShowCursor

I'm attaching today's Thunderbird backtrace.
(Reporter)

Comment 5

3 years ago
Created attachment 8496605 [details]
More nested hanging mac_plugin_interposing_child_OnShowCursor action, this time in THUNDERBIRD

Hangs forever.

Comment 6

3 years ago
I don't think you can get useful samples from a release build, so SupportImageWithMimeType is a red herring.

Since you are only willing to try "fool-proof user-end-oriented" methods, there's probably nothing you can d, other than https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems and reducing the set of extensions and tabs that might affect this.

If you were willing to deal with the more technical and risky stuff, I'd suggest (after backing up your profile) trying a nightly build, which would at least give you correct function names in the sample. And/or the internal profiler https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

I'm sorry you're having this problem, but you have to realize that to diagnose the particular problem you're facing we need more information from you. (And it might not even be diagnosable via bugzilla.) It sucks, but that's unfortunately how it is.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 7

3 years ago
Actually I am quite happy to try to debug this further now that it (or something
very similar) seems to happen with Tunderbird, perhaps in shared mozilla.org code.

Running Firefox, my only browser, in some sort of debugging mode is just too painful
given that I USE the browser and have scores of open tabs of state and can't get by
without Adblock and friends.

On the other hand, the only thing I have installed in Thunderbird are a couple
of dictionaries, and I can live without those, and I only ever have a single
Thunderbird window with a single tab so restarting constantly is never a problem.
(Assuming nothing eats my mail!)

So if somebody were to assign me some end-user task that I can do to try to
gather useful information from an intermittently hanging Thunderbird
running on MacOS 10.6.8 I would be more than happy to help.

Comment 8

3 years ago
Unfortunately I don't use Thunderbird and don't know what tools are available for it. I'd probably start by trying to find a build with proper symbols and/or a version of Gecko Profiler that works on Thunderbird, but you'll need to find somebody who's familiar with Thunderbird in order to get help troubleshooting this. Try support / mailing lists / #thunderbird on IRC?
You need to log in before you can comment on or make changes to this bug.