Closed Bug 789892 Opened 12 years ago Closed 4 years ago

Too Many xmlhttprequest's make Firefox go nuts; "type-inference" memory is very high

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
18 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: brunis, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [MemShrink:P2][js:t])

Attachments

(4 files, 2 obsolete files)

HtmlViewer
59.11 KB, text/plain
Details
xmlhttp
5.52 KB, text/plain
Details
Memory report from mikogo html viewer
33.22 KB, application/octet-stream
Details
memory-report.json.gz
551.25 KB, application/x-gzip
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20120909030609 Steps to reproduce: Joined an Html Viewer session at http://go.mikogo.com Actual results: Firefox performance slowly deteriorates (continuos xmlhttprequests), ending with 100% cpu consumption and 1gb mem usage, if it doesn't crash before that. Expected results: stable cpu/mem consumption, like other browsers
Stupid question: Is it possible that you need a login ? Is a public testcase available somewhere ?
You can download the starter version, host a session and join your own from Firefox. You don't need an account even though it's free.
Component: Untriaged → about:memory
Product: Firefox → Toolkit
WFM on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 using the link from comment3. There is no significant increase in the cpu/mem usage when accessing the link.
Component: about:memory → Untriaged
Product: Toolkit → Firefox
saving the about:memory page doesn't work, you have to copy the text.
Latest Nightly seems to last alot longer, havent crashed it yet. Release and Beta usually die around 1GB memory. But this should be sufficient to see what's wrong. It starts out at 10-15% cpu, but that quickly rises to a full 25% (i have a quadcore cpu) and very sluggish updates. Explicit Allocations 1,553.87 MB (100.0%) -- explicit ├──1,075.98 MB (69.24%) -- window-objects │ ├──1,064.96 MB (68.54%) -- top(https://http-55.mikogo4.com/html.viewer?command=start&simple_mode=no&session_id=&session_password=&screen_name=, id=10) │ │ ├──1,061.82 MB (68.33%) -- active/window(https://http-55.mikogo4.com/html.viewer?command=start&simple_mode=no&session_id=&session_password=&screen_name=) │ │ │ ├──1,060.71 MB (68.26%) -- js/compartment(https://http-55.mikogo4.com/html.viewer?command=start&simple_mode=no&session_id=&session_password=&screen_name=) │ │ │ │ ├────734.37 MB (47.26%) ── analysis-temporary │ │ │ │ ├────168.94 MB (10.87%) -- gc-heap │ │ │ │ │ ├──161.73 MB (10.41%) ── scripts │ │ │ │ │ └────7.21 MB (00.46%) ++ (6 tiny) │ │ │ │ ├─────86.30 MB (05.55%) -- type-inference │ │ │ │ │ ├──86.29 MB (05.55%) ── script-main │ │ │ │ │ └───0.01 MB (00.00%) ── object-main │ │ │ │ ├─────64.78 MB (04.17%) ── script-data │ │ │ │ └──────6.33 MB (00.41%) ++ (6 tiny) │ │ │ └──────1.11 MB (00.07%) ++ (3 tiny) │ │ └──────3.14 MB (00.20%) ++ cached/window(http://devwin:9000/updatecenter#plugin) │ └─────11.02 MB (00.71%) ++ (6 tiny) ├────276.44 MB (17.79%) -- js-non-window │ ├──202.77 MB (13.05%) -- runtime │ │ ├──194.77 MB (12.53%) ── script-sources │ │ └────8.01 MB (00.52%) ++ (14 tiny) │ ├───63.20 MB (04.07%) -- compartments │ │ ├──57.94 MB (03.73%) -- non-window-global │ │ │ ├──42.13 MB (02.71%) ++ (268 tiny) │ │ │ └──15.81 MB (01.02%) ++ compartment([System Principal], jar:file:///C:/Users/dj/AppData/Roaming/Mozilla/Firefox/Profiles/1ac160ob.default/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/bootstrap.js (from: resource:///modules/XPIProvider.jsm:3624)) │ │ └───5.26 MB (00.34%) ++ no-global/compartment(atoms) │ └───10.47 MB (00.67%) ++ gc-heap ├────125.36 MB (08.07%) ── heap-unclassified ├─────54.85 MB (03.53%) -- images │ ├──53.70 MB (03.46%) -- content │ │ ├──52.75 MB (03.39%) -- used │ │ │ ├──48.43 MB (03.12%) ── uncompressed-heap │ │ │ └───4.32 MB (00.28%) ++ (2 tiny) │ │ └───0.95 MB (00.06%) ++ unused │ └───1.14 MB (00.07%) ++ chrome ├─────16.11 MB (01.04%) ++ storage └──────5.14 MB (00.33%) ++ (11 tiny) Other Measurements 288 (100.0%) -- js-compartments ├──276 (95.83%) ── system └───12 (04.17%) ── user 1,346.49 MB (100.0%) -- js-main-runtime ├──1,133.24 MB (84.16%) -- compartments │ ├────741.84 MB (55.09%) ── analysis-temporary │ ├────206.53 MB (15.34%) -- gc-heap │ │ ├──163.49 MB (12.14%) ── scripts │ │ ├───25.41 MB (01.89%) ++ (6 tiny) │ │ └───17.62 MB (01.31%) ── unused-gc-things │ ├─────86.41 MB (06.42%) -- type-inference │ │ ├──86.36 MB (06.41%) ── script-main │ │ └───0.05 MB (00.00%) ++ (2 tiny) │ ├─────69.37 MB (05.15%) ── script-data │ ├─────19.20 MB (01.43%) ── string-chars │ └──────9.90 MB (00.74%) ++ (5 tiny) ├────202.77 MB (15.06%) ── runtime └─────10.47 MB (00.78%) ++ gc-heap 212.27 MB (100.0%) -- js-main-runtime-gc-heap-committed ├──192.28 MB (90.58%) -- used │ ├──188.04 MB (88.58%) ── gc-things │ ├────3.38 MB (01.59%) ── chunk-admin │ └────0.86 MB (00.41%) ── arena-admin └───19.99 MB (09.42%) -- unused ├──17.62 MB (08.30%) ── gc-things └───2.37 MB (01.12%) ++ (2 tiny) 0 (100.0%) -- low-memory-events ├──0 (100.0%) ── physical └──0 (100.0%) ── virtual 5.95 MB (100.0%) -- window-objects ├──3.48 MB (58.50%) -- layout │ ├──2.25 MB (37.78%) ── style-sets │ ├──0.67 MB (11.25%) ── pres-shell │ ├──0.25 MB (04.28%) ── frames │ ├──0.13 MB (02.16%) ── style-contexts │ ├──0.11 MB (01.90%) ── rule-nodes │ └──0.07 MB (01.14%) ++ (3 tiny) ├──1.61 MB (27.10%) -- dom │ ├──1.27 MB (21.39%) ── element-nodes │ ├──0.24 MB (03.98%) ── other │ ├──0.06 MB (01.08%) ── text-nodes │ └──0.04 MB (00.65%) ++ (3 tiny) ├──0.85 MB (14.32%) ── style-sheets └──0.00 MB (00.08%) ── property-tables 8.79 MB ── canvas-2d-pixel-bytes 1,553.75 MB ── explicit 0.03 MB ── gfx-d2d-surfacecache 13.21 MB ── gfx-d2d-surfacevram 34.40 MB ── gfx-d2d-vram-drawtarget 49.44 MB ── gfx-d2d-vram-sourcesurface 49.60 MB ── gfx-surface-image 0 ── ghost-windows 1,330.04 MB ── heap-allocated 1,351.81 MB ── heap-committed 21.75 MB ── heap-committed-unused 1.63% ── heap-committed-unused-ratio 0.21 MB ── heap-dirty 23.96 MB ── heap-unused 48.43 MB ── images-content-used-uncompressed 217.00 MB ── js-gc-heap 0 ── low-commit-space-events 1,643.46 MB ── private 1,701.30 MB ── resident 14.55 MB ── storage-sqlite 2,006.61 MB ── vsize
Nicholas: Sorry that I bother you again but do you know how I could proceed with this report ? I don't know what "analysis-temporary" exactly is....
Component: Untriaged → General
Product: Firefox → Core
Assignee: nobody → general
Component: General → JavaScript Engine
Here's a short profile, i would sample longer if i could without firefox crashing: http://people.mozilla.com/~bgirard/cleopatra/?report=fe8f273240db685d276e5340881395ee3e05148a
> I don't know what "analysis-temporary" exactly is.... It's temporary data for the type inference stuff. Dennis, would you mind attaching the HTMLViewer.js and xmlhttp.js files involved here?
Attached file HtmlViewer —
Attachment #662165 - Attachment is obsolete: true
Attached file xmlhttp —
> It's temporary data for the type inference stuff. I've CC'd some people who know about type inference.
Whiteboard: [MemShrink]
Summary: Too Many xmlhttprequest's make Firefox go nuts → Too Many xmlhttprequest's make Firefox go nuts; "analysis-temporary" memory is very high
Whiteboard: [MemShrink] → [MemShrink:P2]
bhackett, is bug 801799 likely to have effect here as well?
From latest Nightly, not much have changed. Though i did notice that if i'm not showing the tab that streams, memory consumption stays low at ~300MiB .. but having the streaming tab open, quickly ramps up memory use. Main Process Explicit Allocations 1,213.25 MB (100.0%) -- explicit ├────774.76 MB (63.86%) -- window-objects │ ├──767.37 MB (63.25%) -- top(https://http-55.mikogo4.com/html.viewer?command=start&simple_mode=no&session_id=&session_password=&screen_name=, id=75) │ │ ├──762.47 MB (62.85%) -- active/window(https://http-55.mikogo4.com/html.viewer?command=start&simple_mode=no&session_id=&session_password=&screen_name=) │ │ │ ├──761.36 MB (62.75%) -- js/compartment(https://http-55.mikogo4.com/html.viewer?command=start&simple_mode=no&session_id=&session_password=&screen_name=) │ │ │ │ ├──531.37 MB (43.80%) ── analysis-temporary │ │ │ │ ├──119.00 MB (09.81%) -- gc-heap │ │ │ │ │ ├──117.14 MB (09.66%) ── scripts │ │ │ │ │ └────1.85 MB (00.15%) ++ (6 tiny) │ │ │ │ ├───62.52 MB (05.15%) -- type-inference │ │ │ │ │ ├──62.51 MB (05.15%) ── script-main │ │ │ │ │ └───0.01 MB (00.00%) ── object-main │ │ │ │ ├───46.94 MB (03.87%) ── script-data │ │ │ │ └────1.53 MB (00.13%) ++ (5 tiny) │ │ │ └────1.12 MB (00.09%) ++ (3 tiny) │ │ └────4.90 MB (00.40%) ++ cached/window(http://ie.microsoft.com/testdrive/Performance/MazeSolver/Default.html) │ └────7.39 MB (00.61%) ++ (6 tiny) ├────226.90 MB (18.70%) -- js-non-window │ ├──145.43 MB (11.99%) -- runtime │ │ ├──141.15 MB (11.63%) ── script-sources │ │ └────4.28 MB (00.35%) ++ (13 tiny) │ ├───54.36 MB (04.48%) -- compartments │ │ ├──49.02 MB (04.04%) -- non-window-global │ │ │ ├──31.88 MB (02.63%) ++ (246 tiny) │ │ │ └──17.14 MB (01.41%) ++ compartment([System Principal], jar:file:///C:/Users/dj/AppData/Roaming/Mozilla/Firefox/Profiles/1ac160ob.default/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/bootstrap.js (from: resource://gre/modules/XPIProvider.jsm:3624)) │ │ └───5.34 MB (00.44%) ++ no-global/compartment(atoms) │ └───27.12 MB (02.24%) ++ gc-heap ├────101.05 MB (08.33%) ── heap-unclassified ├─────76.90 MB (06.34%) -- images │ ├──76.63 MB (06.32%) -- content │ │ ├──71.65 MB (05.91%) -- used │ │ │ ├──58.85 MB (04.85%) ── uncompressed-heap │ │ │ ├──12.80 MB (01.06%) ── raw │ │ │ └───0.00 MB (00.00%) ── uncompressed-nonheap │ │ └───4.98 MB (00.41%) ++ unused │ └───0.27 MB (00.02%) ++ chrome ├─────17.71 MB (01.46%) -- storage │ ├──16.13 MB (01.33%) ++ sqlite │ └───1.58 MB (00.13%) ++ prefixset └─────15.93 MB (01.31%) ++ (13 tiny) Other Measurements 266 (100.0%) -- js-compartments ├──253 (95.11%) ── system └───13 (04.89%) ── user 994.75 MB (100.0%) -- js-main-runtime ├──822.21 MB (82.65%) -- compartments │ ├──537.72 MB (54.06%) ── analysis-temporary │ ├──152.88 MB (15.37%) -- gc-heap │ │ ├──118.58 MB (11.92%) ── scripts │ │ ├───18.00 MB (01.81%) ++ (6 tiny) │ │ └───16.30 MB (01.64%) ── unused-gc-things │ ├───62.60 MB (06.29%) -- type-inference │ │ ├──62.57 MB (06.29%) ── script-main │ │ └───0.03 MB (00.00%) ── object-main │ ├───50.73 MB (05.10%) ── script-data │ ├───10.38 MB (01.04%) ++ string-chars │ └────7.88 MB (00.79%) ++ (8 tiny) ├──145.43 MB (14.62%) ── runtime └───27.12 MB (02.73%) -- gc-heap ├──11.96 MB (01.20%) ── unused-arenas ├──11.36 MB (01.14%) ── decommitted-arenas └───3.80 MB (00.38%) ++ (2 tiny) 168.64 MB (100.0%) -- js-main-runtime-gc-heap-committed ├──139.38 MB (82.65%) -- used │ ├──135.93 MB (80.61%) ── gc-things │ ├────2.80 MB (01.66%) ── chunk-admin │ └────0.65 MB (00.38%) ── arena-admin └───29.26 MB (17.35%) -- unused ├──16.30 MB (09.67%) ── gc-things ├──11.96 MB (07.09%) ── arenas └───1.00 MB (00.59%) ── chunks 0 (100.0%) -- low-memory-events ├──0 (100.0%) ── physical └──0 (100.0%) ── virtual 6.93 MB (100.0%) -- window-objects ├──4.84 MB (69.78%) -- layout │ ├──2.06 MB (29.72%) ── style-sets │ ├──1.26 MB (18.12%) ── pres-shell │ ├──0.88 MB (12.65%) ── frames │ ├──0.22 MB (03.24%) ── style-contexts │ ├──0.20 MB (02.94%) ── rule-nodes │ ├──0.20 MB (02.88%) ── pres-contexts │ └──0.02 MB (00.24%) ++ (2 tiny) ├──1.56 MB (22.55%) -- dom │ ├──1.32 MB (19.05%) ── element-nodes │ ├──0.18 MB (02.57%) ── other │ └──0.06 MB (00.93%) ++ (4 tiny) ├──0.53 MB (07.65%) ── style-sheets └──0.00 MB (00.02%) ── property-tables 8.82 MB ── canvas-2d-pixel-bytes 1,213.08 MB ── explicit 0.00 MB ── gfx-d2d-surfacecache 12.89 MB ── gfx-d2d-surfacevram 25.24 MB ── gfx-d2d-vram-drawtarget 59.00 MB ── gfx-d2d-vram-sourcesurface 59.13 MB ── gfx-surface-image 0 ── ghost-windows 1,023.18 MB ── heap-allocated 1,049.04 MB ── heap-committed 25.85 MB ── heap-committed-unused 2.52% ── heap-committed-unused-ratio 2.85 MB ── heap-dirty 50.82 MB ── heap-unused 58.85 MB ── images-content-used-uncompressed 180.00 MB ── js-gc-heap 0 ── low-commit-space-events 1,294.13 MB ── private 1,349.86 MB ── resident 16.13 MB ── storage-sqlite 1,637.45 MB ── vsize
(In reply to Nicholas Nethercote [:njn] from comment #14) > bhackett, is bug 801799 likely to have effect here as well? When bug 778724 is reenabled it should help this; the analysis-temporary numbers here are well above the default threshold that will trigger a purge there. I suspect what's going on in this bug is not that TI is going nuts, but that there are a ton of scripts being executed a few times each (see large memory under gc-heap/scripts and type-inference/script-main), which will not cause TI to run but will cause the bytecode to be analyzed. The latter analysis information is likely to be filling up analysis-temporary.
(In reply to Brian Hackett (:bhackett) [mostly gone until mid-November] from comment #16) > (In reply to Nicholas Nethercote [:njn] from comment #14) > > bhackett, is bug 801799 likely to have effect here as well? > > When bug 778724 is reenabled it should help this; bug# ? Dennis' crash is bp-cc9958d2-786b-49c9-947b-8ea5c2121001 @ js::GCMarker::processMarkStackTop(js::SliceBudget&)
Severity: normal → critical
Crash Signature: [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)]
Keywords: crash
Whiteboard: [MemShrink:P2] → [MemShrink:P2][js:t]
Is this still a problem? Type inference memory consumption has had some more improvements lately.
yes, same as always. I'm attaching the txt copy from about:memory
Summary: Too Many xmlhttprequest's make Firefox go nuts; "analysis-temporary" memory is very high → Too Many xmlhttprequest's make Firefox go nuts; "type-inference" memory is very high
I don't think bug 778724 is ever actually going to be reenabled. This should be fixed by bug 804676, which is blocked on the baseline compiler. After that is in place we'll only be analyzing scripts which are hot enough to be compiled by baseline so should never need to do any analysis / allocate memory for these run-once scripts (assuming comment 16's diagnosis is correct).
Depends on: 804676
We're seeing similar issues with a Comet implementation (as Forever XHR); sometimes OnReadyStateChanged event is fired multiple times after a new connection to the server is established. Sometimes they will stop after a couple of seconds, but there are cases when it never stops. Please contact me via email for a list of steps to reproduce. Cheers,
> This should be fixed by bug 804676. The patches for that bug just landed on mozilla-inbound. Hopefully tomorrow's Nightly build will contain them. Dennis, could you try again then? Thanks!
Unfortunately (In reply to Nicholas Nethercote [:njn] from comment #24) > > This should be fixed by bug 804676. > > The patches for that bug just landed on mozilla-inbound. Hopefully > tomorrow's Nightly build will contain them. Dennis, could you try again > then? Thanks! Unfortunately bug 804676 morphed and the work required here of not analyzing scripts until they are compiled by baseline is not yet done. That requires JM to be removed, which is not I think going to happen for a few weeks.
Depends on: 865059
> Unfortunately bug 804676 morphed and the work required here of not analyzing > scripts until they are compiled by baseline is not yet done. That requires > JM to be removed, which is not I think going to happen for a few weeks. Ah, ok. Should I make this bug depend on bug 857845, and also move the MemShrink:P1 tag from bug 804676 to bug 857845?
I filed bug 865059 for the analysis work that should fix this bug; bug 857845 doesn't by itself improve anything but will unblock bug 865059. I don't really know what the MemShrink tags are supposed to indicate with fixed bugs, but bug 804676 should improve memory usage in cases where we are Ion compiling a lot of code. It just won't help with this bug by itself.
Attachment #711094 - Attachment is obsolete: true
This signature has been an unactionable topcrash for quite some time (see bug 719114). Is this bug report a dupe or simply another case which triggers it?
Assignee: general → nobody
Crash Signature: [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] → [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackTop]
This code has changed a lot in the last 3 years, so I'm going to mark this bug incomplete.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Using the repro steps, Firefox still consumes all available memory until it crashes.
Alright, thanks for the update.
Status: RESOLVED → REOPENED
Crash Signature: [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackTop]
Ever confirmed: true
Resolution: INCOMPLETE → ---
Still a problem and it's becoming apparent on more and more big websites like facebook, that constantly ajax'es all kinds of services in the background, messenger, chat, load-on-demand, etc. You dont have to sit on facebook and scroll down very far before things start stuttering, especially apparent in the new like bar, when you try to like a post the emoji's will animate with a lot of stuttering. The crash is just postponed a lot longer now with 64bit builds being the default.
Dennis, would you be able to grab an about:memory dump from a session showing the problem? Bug 865059 was supposed to fix the type-inference memory issue, so presumably either it didn't or there's another memory issue here too...
Attached file memory-report.json.gz —
Dennis, thank you. In that dump, the main interesting things I see memory-wise are: 1) In the process that mikogo.com is loaded in, ~750MB of images. In particular, a huge number of 1920x64 images, about 0.5MB each, with URLs like "https://http-78.mikogo4.com/html.viewer?command=get_session_box&box_id=14&stamp=353&session_id=191186004&viewer_id=1,31883298,1,1&viewer_server_i...." and also a large number of 160KB 640x64 images. 2) 144M of profiler state in that same process. Do you have the Gecko profiler enabled? Does disabling it help at all? I don't see all that much memory usage in the process facebook is in, or any of the other processes.
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #36) > Dennis, thank you. In that dump, the main interesting things I see > memory-wise are: > > 1) In the process that mikogo.com is loaded in, ~750MB of images. In > particular, a huge number of 1920x64 images, about 0.5MB each, with URLs like > "https://http-78.mikogo4.com/html. > viewer?command=get_session_box&box_id=14&stamp=353&session_id=191186004&viewe > r_id=1,31883298,1,1&viewer_server_i...." and also a large number of 160KB > 640x64 images. Yeah, i didn't let it run long. It's a webbased version of the Mikogo screensharing software, it just spams requests for images, i'm guessing that was the way to do "video" back then. I'll do another session with just the html Mikogo viewer, no other tabs and let it run until it consumes more, but i'm guessing it's just piling up the images and they dont get gc'ed. Still, would be nice to dispose of these images that are barely used .1s > 2) 144M of profiler state in that same process. Do you have the Gecko > profiler enabled? Does disabling it help at all? I could disable it, but it doesn't make much of a difference. > I don't see all that much memory usage in the process facebook is in, or any > of the other processes. I think i'll try to submit a different bug for the facebook issue, it's just a matter of scrolling your feed long enough, animated emoticons will start stuttering when you want to like posts. Could be addon related, can't say for sure. I have an AdBlocker and the "Facebook container".

(In reply to Dennis Jakobsen from comment #37)

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from
comment #36)
...

I don't see all that much memory usage in the process facebook is in, or any
of the other processes.

I think i'll try to submit a different bug for the facebook issue, it's just
a matter of scrolling your feed long enough, animated emoticons will start
stuttering when you want to like posts. Could be addon related, can't say
for sure. I have an AdBlocker and the "Facebook container".

Dennis, what did you determine?

Flags: needinfo?(brunis)
Status: REOPENED → RESOLVED
Closed: 8 years ago → 4 years ago
Resolution: --- → INACTIVE
Flags: needinfo?(brunis)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: