Closed Bug 685508 Opened 13 years ago Closed 13 years ago

[Mac 10.7] Freeze of whole machine with Nightly after few ours of run

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
9 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mayhemer, Unassigned)

Details

(Whiteboard: [MemShrink])

Attachments

(3 files)

Sample
71.00 KB, text/plain
Details
Sample 2, hi CPU load
330.92 KB, text/plain
Details
Two sample after restart, 100+% CPU load
52.13 KB, application/zip
Details
Attached file Sample — 
Mac OS X 10.7.1
http://hg.mozilla.org/mozilla-central/rev/1881f9b5f8b5

I woke up my older iMac with 4 GB of memory after some 12 hours and the machine was completely frozen, barely responding.  I suspect the problem started even before I put the mac to sleep because it took a long time for it to actually sleep after pressing the power button.  Nightly ran for few hours with some tabs described bellow open.

I managed to create a sample of the Nightly process (attached).

Immediately I have killed Nightly the machine started to respond normally again.  It appeared to me as a huge memory leak, but it is a guess, I unfortunately didn't check the memory levels.

I had 3 tabs with tbpl and some 5 tabs with Talos result details (Perfstatic) then following other tabs:
http://www.simpsonovi-online-shlednuti.cz/epizody-zdarma/sila-talentu/
http://www.medard-online.cz/index.php (the Cloudiness page)

Some of them might help to reproduce this.
This sounds like a leak. About:memory would have been very useful, too (next time).
Whiteboard: [MemShrink]
(In reply to Andreas Gal :gal from comment #1)
> This sounds like a leak. About:memory would have been very useful, too (next
> time).

I will remember this.  However the UI was completely non-responsive.  So I couldn't open it even I would remember to do it.  Unfortunatelly I didn't check the memory state in the activity monitor either.
Looks like I was able to reproduce.

Bellow is about:memory printout, you can see that graphs.mozilla.org eats:

The URLs I have open on this site:
http://graphs.mozilla.org/graph.html#type=series&tests=[{%22test%22:%2282%22,%22branch%22:%2223%22,%22machine%22:%22518%22,%22testrun%22:%228277945%22}]
http://graphs.mozilla.org/graph.html#type=series&tests=[{%22test%22:%2283%22,%22branch%22:%2223%22,%22machine%22:%22518%22,%22testrun%22:%228277946%22}]
http://graphs.mozilla.org/graph.html#type=series&tests=[{%22test%22:%2216%22,%22branch%22:%2223%22,%22machine%22:%22513%22,%22testrun%22:%228277971%22}]
http://graphs.mozilla.org/graph.html#type=series&tests=[{%22test%22:%2236%22,%22branch%22:%2223%22,%22machine%22:%22513%22,%22testrun%22:%228277972%22}]
http://graphs.mozilla.org/graph.html#type=series&tests=[{%22test%22:%2236%22,%22branch%22:%2223%22,%22machine%22:%22513%22,%22testrun%22:%228277972%22}]


Main Process

Explicit Allocations
1,909.42 MB (100.0%) -- explicit
├──1,727.03 MB (90.45%) -- js
│  ├──1,591.65 MB (83.36%) -- compartment(http://graphs.mozilla.org/graph.html#typ...)
│  │  ├──1,156.57 MB (60.57%) -- gc-heap
│  │  │  ├────650.36 MB (34.06%) -- objects
│  │  │  ├────413.28 MB (21.64%) -- strings
│  │  │  ├─────73.61 MB (03.86%) -- arena-unused
│  │  │  └─────19.31 MB (01.01%) -- (3 omitted)
│  │  ├────404.21 MB (21.17%) -- object-slots
│  │  ├─────27.86 MB (01.46%) -- string-chars
│  │  └──────3.01 MB (00.16%) -- (4 omitted)
│  ├─────42.36 MB (02.22%) -- gc-heap-chunk-dirty-unused
│  ├─────28.12 MB (01.47%) -- compartment(https://tbpl.mozilla.org/?tree=Try&usebu...)
│  │     ├──15.08 MB (00.79%) -- gc-heap
│  │     │  └──15.08 MB (00.79%) -- (6 omitted)
│  │     └──13.04 MB (00.68%) -- (8 omitted)
│  ├─────22.27 MB (01.17%) -- compartment([System Principal], 0x104869a00)
│  │     ├──11.96 MB (00.63%) -- gc-heap
│  │     │  └──11.96 MB (00.63%) -- (7 omitted)
│  │     └──10.31 MB (00.54%) -- (7 omitted)
│  ├─────21.70 MB (01.14%) -- gc-heap-chunk-admin
│  └─────20.92 MB (01.10%) -- (16 omitted)
├─────97.26 MB (05.09%) -- heap-unclassified
├─────43.60 MB (02.28%) -- storage
│     └──43.60 MB (02.28%) -- sqlite
│        ├──28.84 MB (01.51%) -- urlclassifier3.sqlite
│        │  ├──28.75 MB (01.51%) -- cache-used
│        │  └───0.10 MB (00.01%) -- (2 omitted)
│        └──14.75 MB (00.77%) -- (14 omitted)
├─────18.70 MB (00.98%) -- layout
│     ├──15.36 MB (00.80%) -- arenas
│     └───3.33 MB (00.17%) -- (1 omitted)
├─────12.71 MB (00.67%) -- (5 omitted)
└─────10.13 MB (00.53%) -- dom

Other Measurements
   25.88 MB -- canvas-2d-pixel-bytes
    4.17 MB -- gfx-surface-image
  637.64 MB -- heap-allocated
   88.98 MB -- heap-unallocated
  637.65 MB -- heap-zone0-committed
  718.63 MB -- heap-zone0-used
          3 -- js-compartments-system
         20 -- js-compartments-user
1,256.00 MB -- js-gc-heap
   82.12 MB -- js-gc-heap-arena-unused
    0.00 MB -- js-gc-heap-chunk-clean-unused
   42.36 MB -- js-gc-heap-chunk-dirty-unused
      9.91% -- js-gc-heap-unused-fraction
     17,410 -- page-faults-hard
  2,308,402 -- page-faults-soft
2,019.89 MB -- resident
    0.00 MB -- shmem-allocated
    0.00 MB -- shmem-mapped
5,182.06 MB -- vsize
Attached file Sample 2, hi CPU load — 
There was also hi CPU load at the same time I was snapping about:memory.  This is the sample from the same time.

I also experience CPU load after I have restarted when uploading this file.  Fx was dead for few seconds with 100% CPU load.  And UI is choking as I type right now.  But may be caused by some Flash videos and ads in background tabs..

These are exactly the bugs why people turn away to different browsers :(  I will do as much as I can to fix at least this particular one...
These are two samples I took after restart.  UI almost unresponsive for several seconds.

Update on the previous comment:
graphs.mozilla.org allocate so much memory right after start, so if there is a leak it affects early during build time of the page.
It's not clear to me that this is a browser bug and not a problem in graphserver.
I tried to look at this in Chrome to see if it's a problem with us or the page, but the graphserver link from comment 3 spins and doesn't load in Chrome.
(In reply to Justin Lebar [:jlebar] from comment #7)
> I tried to look at this in Chrome to see if it's a problem with us or the
> page, but the graphserver link from comment 3 spins and doesn't load in
> Chrome.

We're working on replacing this version of graphserver - I would be curious to know if an equivalent graph on http://graphs-new.mozilla.org/graph.html would cause the same problem (it's a totally new front-end).

The older graphserver code uses custom canvas code which is in maintenance mode.
(In reply to Justin Lebar [:jlebar] from comment #7)
> I tried to look at this in Chrome to see if it's a problem with us or the
> page, but the graphserver link from comment 3 spins and doesn't load in
> Chrome.

Same thing in Safari.
(In reply to Andrew McCreight [:mccr8] from comment #9)
> (In reply to Justin Lebar [:jlebar] from comment #7)
> > I tried to look at this in Chrome to see if it's a problem with us or the
> > page, but the graphserver link from comment 3 spins and doesn't load in
> > Chrome.
> 
> Same thing in Safari.

graphserver 1.0 only supports Firefox, the newer version is tested in Firefox and Chrome (partly to have a reference point for bugs like this :) ).

It might be easiest to extract a test case from the graphserver, and decide if it's particularly pathological or not. I don't know of any other sites which use the homegrown canvas graphing library it does though.
The new graphserver uses *much* less memory.

Let's close this INVALID?  It sounds very likely that the problem is graphserver 1.0.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
This bug indicates we should limit the memory a single page and/or the complete set of pages open use.  It is nice to close this as INVALID but I don't care that the cause is a faulty site.  There may be thousands of other sites like this.

I wanted to point out with this bug that I perceive Firefox as an unstable and memory eating application that is capable to completely collapse my machine while just browsing and that this is exactly reason to migrate to a different browser.

I know this is a larger scope think to solve, but we have to solve the issue(s) in Firefox code this to never happen again.

The old graphserver could be used to track the issue down or as a test case to check we are able to limit an insanely consuming site from breaking ones computer down.

Hawk.
If the bug is "don't let pages DOS the browser by consuming lots of resources", can you please file that separately?

FWIW, there are tons of known DOS bugs.
(In reply to Justin Lebar [:jlebar] from comment #13)
> If the bug is "don't let pages DOS the browser by consuming lots of
> resources", can you please file that separately?

Yes, I'll try to formulate my thoughts more technically in that bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: