Excessive memory usage at "amazon shelf" test drive ending in crash at _cairo_d2d_create_brush_for_pattern
RESOLVED
WORKSFORME
Status
()
People
(Reporter: scoobidiver, Assigned: bas.schouten)
Tracking
(Blocks: 1 bug, {crash, regression})
Firefox Tracking Flags
(blocking2.0 -)
Details
(Whiteboard: estimated-time: 1 day, ietestdrive, crash signature, URL)
Attachments
(4 attachments)
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•9 years ago
|
||
Created attachment 467803 [details] Memory usage a few seconds before crash (D2D on)
those reports aren't working. can you please poke them from about:crashes (click them again?)
(Reporter) | ||
Comment 3•9 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•9 years ago
|
||
Created attachment 468131 [details]
Windbg log (D2D on)
(Reporter) | ||
Updated•9 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•9 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•9 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"
Attachment #468131 -
Attachment mime type: application/octet-stream → text/plain
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)
Created attachment 473716 [details]
about:support
(Reporter) | ||
Updated•9 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•9 years ago
|
||
Is something forecast to prevent the growing of memory usage ?
blocking2.0: --- → ?
Updated•9 years ago
|
Assignee: nobody → bas.schouten
blocking2.0: ? → betaN+
(Assignee) | ||
Comment 10•9 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•9 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?
Updated•8 years ago
|
Keywords: crash, regression
(Assignee) | ||
Comment 14•8 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•8 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•8 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+ → ?
Updated•8 years ago
|
blocking2.0: ? → -
Updated•8 years ago
|
Crash Signature: [@ cairo_d2d_create_brush_for_pattern ]
[@ _cairo_d2d_create_brush_for_pattern(_cairo_d2d_surface*, _cairo_pattern const*, bool) ]
Comment 17•8 years ago
|
||
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
Comment 19•3 years ago
|
||
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: 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•