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

RESOLVED WORKSFORME

Status

()

Core
Graphics
--
critical
RESOLVED WORKSFORME
8 years ago
2 years ago

People

(Reporter: Scoobidiver (away), Assigned: bas)

Tracking

(Blocks: 2 bugs, {crash, regression})

Trunk
x86_64
Windows 7
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: estimated-time: 1 day, ietestdrive, crash signature, URL)

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

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

Comment 2

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

Comment 3

8 years ago
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
(Reporter)

Comment 4

8 years ago
Created attachment 468131 [details]
Windbg log (D2D on)
(Reporter)

Updated

8 years ago
Component: General → Graphics
QA Contact: general → thebes
Summary: Memory leak at "amazon shelf" test drive ending in crash → Exponential memory leak at "amazon shelf" test drive ending in crash [@ cairo_d2d_create_brush_for_pattern ]
(Assignee)

Comment 5

8 years ago
Although this is certainly an issue it's not a leak. If I close the tab all the memory is reclaimed.
Summary: Exponential memory leak at "amazon shelf" test drive ending in crash [@ cairo_d2d_create_brush_for_pattern ] → Excessive memory usage at "amazon shelf" test drive ending in crash [@ cairo_d2d_create_brush_for_pattern ]
(Assignee)

Comment 6

8 years ago
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"

Updated

8 years ago
Attachment #468131 - Attachment mime type: application/octet-stream → text/plain

Comment 7

8 years ago
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

8 years ago
Created attachment 473716 [details]
about:support
(Reporter)

Updated

8 years ago
Summary: Excessive memory usage at "amazon shelf" test drive ending in crash [@ cairo_d2d_create_brush_for_pattern ] → Excessive memory usage at "amazon shelf" test drive ending in crash [@ cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ]
(Reporter)

Comment 9

8 years ago
Is something forecast to prevent the growing of memory usage ?
blocking2.0: --- → ?
Assignee: nobody → bas.schouten
blocking2.0: ? → betaN+
(Assignee)

Comment 10

8 years ago
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?
well, presumably someone could keep calling save() without a corresponding restore().. not sure what else could be doing it
(Assignee)

Comment 12

8 years ago
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.
Whiteboard: estimated-time: 1 day
(Reporter)

Updated

8 years ago
Whiteboard: estimated-time: 1 day → estimated-time: 1 day, ietestdrive
(Reporter)

Comment 13

8 years ago
Does anybody work on this?
Keywords: crash, regression
(Assignee)

Comment 14

7 years ago
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.
(Assignee)

Comment 15

7 years ago
We need to consider unblocking. Since the demo is no longer working it seems unlikely we can investigate this for beta 9.
(Assignee)

Comment 16

7 years ago
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.
blocking2.0: betaN+ → ?
blocking2.0: ? → -
Crash Signature: [@ cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ]
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.
Crash Signature: [@ cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ] → [@ cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ]
(Reporter)

Comment 18

7 years ago
There are still crashes with this crash signature:
https://crash-stats.mozilla.com/report/list?signature=_cairo_d2d_create_brush_for_pattern
Crash Signature: [@ cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ] → [@ _cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ]
Summary: Excessive memory usage at "amazon shelf" test drive ending in crash [@ cairo_d2d_create_brush_for_pattern ] [@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ] → Excessive memory usage at "amazon shelf" test drive ending in crash at _cairo_d2d_create_brush_for_pattern
Blocks: 918620
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.