589195 - Excessive memory usage at "amazon shelf" test drive ending in crash at _cairo_d2d_create_brush_for_pattern

Status: RESOLVED WORKSFORME

Description

[Scoobidiver (away)]

Created attachment 467802 [details]
Taskmanager soon after crash (D2D on)

Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4

Step to reproduce :
1. Open task manager
1. Go to the ref URL
2. Wait a few minutes until FF crashes

If D2D on, RAM increases in exponential way and the crash happens at about 2.3 GB.
If D2D off, RAM increases in exponential way at the beginning and stabilizes at about 2.6 GB without crash. Opening a new tab crashes FF.

http://crash-stats.mozilla.com/report/pending/a2f5e3a8-5987-46fc-9213-609da2100820
http://crash-stats.mozilla.com/report/pending/964668e1-192e-47ac-b150-e580f2100820
http://crash-stats.mozilla.com/report/pending/cd10e33f-834a-45f6-a1eb-2654b2100820

Comment 1

[Scoobidiver (away)]

Created attachment 467803 [details]
Memory usage a few seconds before crash (D2D on)

Comment 2

[timeless]

those reports aren't working. can you please poke them from about:crashes (click them again?)

Comment 3

[Scoobidiver (away)]

These reports are in :
+ submitted state in my hard drive : C:\users\..\Firefox\Crash reports\submitted
+ pending state in socorro that is queued for more than 2 days

The important thing in that bug is not the crash reason which is probably an out-of-memory crash, but the memory leak in an incremental way

Comment 4

[Scoobidiver (away)]

Created attachment 468131 [details]
Windbg log (D2D on)

Comment 5

[Bas Schouten (:bas.schouten)]

Although this is certainly an issue it's not a leak. If I close the tab all the memory is reclaimed.

Comment 6

[Bas Schouten (:bas.schouten)]

I checked this with GlowCode, the following stack trace appears to be responsible for the allocations that are causing the excessive memory usage, indeed it seems it all gets de-allocated when the surface is destroyed.

StackTrace Content
  "MSVCR90D!malloc_base+254 bytes, 0x6E6C103E"
  "MSVCR90D!malloc_dbg+774 bytes, 0x6E6CFD76"
  "MSVCR90D!malloc_dbg+191 bytes, 0x6E6CFB2F"
  "MSVCR90D!malloc_dbg+108 bytes, 0x6E6CFADC"
  "MSVCR90D!malloc+27 bytes, 0x6E6DB25B"
  "xul!_cairo_path_buf_create, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\cairo\cairo\src\cairo-path-fixed.c, line 703+81 bytes, 0x11208D9D"
  "xul!_cairo_path_fixed_init_copy, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\cairo\cairo\src\cairo-path-fixed.c, line 146+9 bytes, 0x11207B65"
  "xul!_cairo_clip_intersect_path, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\cairo\cairo\src\cairo-clip.c, line 358+16 bytes, 0x11201493"
  "xul!_cairo_clip_clip, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\cairo\cairo\src\cairo-clip.c, line 393+30 bytes, 0x112012AE"
  "xul!_cairo_gstate_clip, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\cairo\cairo\src\cairo-gstate.c, line 1386+44 bytes, 0x1120633F"
  "xul!_moz_cairo_clip_preserve, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\cairo\cairo\src\cairo.c, line 2618+22 bytes, 0x111C5165"
  "xul!gfxContext::Clip, file c:\users\bas\development\mozilla\mozilla-central-clean\gfx\thebes\gfxcontext.cpp, line 640+12 bytes, 0x100535C3"
  "xul!nsCanvasRenderingContext2D::Clip, file c:\users\bas\development\mozilla\mozilla-central-clean\content\canvas\src\nscanvasrenderingcontext2d.cpp, line 2103+0 bytes, 0x105B0B75"

Comment 7

[MrX1980]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre

memory usage growing -> crash

submit.log
[09/09/10 22:26:48] Crash report submission failed: Der Vorgang wurde erfolgreich beendet.


http://crash-stats.mozilla.com/report/pending/83acc949-8100-471b-9247-de9822100909
Oh Noes!
This archived report could not be located.


about:support
(see attachment)

Comment 8

[MrX1980]

Created attachment 473716 [details]
about:support

Comment 9

[Scoobidiver (away)]

Is something forecast to prevent the growing of memory usage ?

Comment 10

[Bas Schouten (:bas.schouten)]

Vlad, I'd like your opinion on this, looking at the stack trace I posted here, do you see any way a Canvas user could cause more and more clips to be stored for a surface, causing a lot of memory usage there?

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

well, presumably someone could keep calling save() without a corresponding restore().. not sure what else could be doing it

Comment 12

[Bas Schouten (:bas.schouten)]

For a time estimate on this bug, it requires a little bit of work. But I don't expect it to be too much, guessing at 1 day.

Comment 13

[Scoobidiver (away)]

Does anybody work on this?

Comment 14

[Bas Schouten (:bas.schouten)]

So I think what this is doing is just clipping again and again, without ever calling save or restore. This would keep allocating more and more clips inside cairo. IE9 presumably just intersects the clips each time not having this memory problem. Sadly the demo is not function at the moment and I can't test this hypothesis.

If this is the case though it's really kind of a bug in the demo and there's not a real bug for us to fix here.

Comment 15

[Bas Schouten (:bas.schouten)]

We need to consider unblocking. Since the demo is no longer working it seems unlikely we can investigate this for beta 9.

Comment 16

[Bas Schouten (:bas.schouten)]

I suggest we unblock. The demo is still gone and I still don't think this is actually a bug. Nor do we have any other reports of similar behavior.

Comment 17

[Marco Castelluccio [:marco]]

I've the same problem with this other test: https://ie.microsoft.com/testdrive/Performance/Paintball/Default.html

The problem happens only if the test is in the current tab.
During the test the CPU usage is normal, but when the test ends, when you can see the results, the CPU usage goes up to 25% (an entire CPU, as I've a quad-core) and the memory constantly gets allocated and freed cyclically (so Firefox doesn't crash).

Firefox 8.0a2 under Windows 7 64 bit, D2D active.

Comment 18

[Scoobidiver (away)]

There are still crashes with this crash signature:
https://crash-stats.mozilla.com/report/list?signature=_cairo_d2d_create_brush_for_pattern

Comment 19

[Michelle Funches - QA]

This bug has been tagged for regression and/or closure.

Version 	46.0.1
Build ID 	20160502172042
Working as expected, no crashes,high CPU or Memory issues observed.
Considering this, I will resolve as WFM. 
Feel free to re-open if the error resurfaces on a recent build.