Firefox crashes when manipulating an SVG file

RESOLVED FIXED

Status

()

Core
SVG
--
critical
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: Peter Szabó, Assigned: bas)

Tracking

({crash, regression})

37 Branch
x86
Windows
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

User Story

Caused by https://hg.mozilla.org/integration/mozilla-inbound/rev/4f086025350f which was from 934305 (despite what the mistaken commit message says)

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8600264 [details]
Open Index.html in Firefox and see the browser crashing

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

Steps to reproduce:

I was manipulating an SVG file with JavaScript


Actual results:

The browser crashes


Expected results:

The browser should not crash :)
I can confirm a OOM crash with Firefox37 on Windows7
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::vector<ots::OpenTypeCMAPSubtableRange, std::allocator<ots::OpenTypeCMAPSubtableRange> >::_Reallocate(unsigned int) ]
Component: Untriaged → SVG
Ever confirmed: true
Keywords: crash
OS: Unspecified → Windows
Product: Firefox → Core
Hardware: Unspecified → x86
Can you add the report ids (including the bp) from about:crashes please
(Reporter)

Comment 3

3 years ago
bp-88c9c843-6655-4edc-975c-800072150501
bp-7ae723e7-7701-4145-aed3-5c5ed2150427
bp-965591ac-1fb1-4dec-84d5-d741a2150427
bp-cfff3941-ead8-4f8d-959e-255192150427
bp-406148ca-a4ca-403d-9e1e-d52922150427

Comment 4

3 years ago
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=92f737230338&tochange=af0931327e49

Triggered by: Bug 651858
Blocks: 651858

Updated

3 years ago
Keywords: regression

Comment 5

3 years ago
Sorry,
it should be Bug 930577
Blocks: 930577
No longer blocks: 651858

Updated

3 years ago
Flags: needinfo?(jwatt)
Blocks: 934305
User Story: (updated)
Peter, would you be able to reduce your testcase to something considerably smaller by incrementally chopping bits out of it until you can no longer remove any more without the crash failing to occur?
Flags: needinfo?(jwatt) → needinfo?(petersz.szabo)
(Reporter)

Comment 7

3 years ago
Created attachment 8607043 [details]
testcase.zip
Flags: needinfo?(petersz.szabo)
That's much better, but I'm not familiar with DrawSVGPlugin or TweenMax. Can you also get rid of those?
(Reporter)

Comment 9

3 years ago
Unfortunately neither I'm familiar with those libraries. They are third-party libraries from http://greensock.com/drawSVG
But I assume you wrote the code:

  TweenMax.staggerTo("#main-line-10", 0, {drawSVG: 0}, 0);

Can you explain what that does? The staggerTo part seems to essentially do some sort of step from one value to another, but the {drawSVG: 0} part and what the value is changing to is not at all clear.
(Reporter)

Comment 11

3 years ago
I wanted to create an animation, which draws the paths of an SVG image.

To achieve that, I "initialize" the SVG by calling the mentioned function to display "0%" of the given SVG path.

Then I call TweenMax.staggerTo("#main-line-10", 0.5, {drawSVG: "100%"}, 0.1); to slowly draw the full path.

Basically something similar to this: http://codepen.io/netgfx/pen/OPNOgM

I was able to draw other SVG paths, only the one in the attached HTML file is causing the browser to crash.
Created attachment 8607227 [details]
reduced testcase (WATCH OUT! HANG/CRASH!)

Does this still cause issues on Windows?
Attachment #8607227 - Attachment description: reduced testcase → reduced testcase (WATCH OUT! HANG/CRASH!)
(Reporter)

Comment 13

3 years ago
Yes, It does.
Great, thanks for your help reducing the testcase.

Bas, can you take a look at what's going wrong with the path measuring code?
Flags: needinfo?(bas)
(Assignee)

Updated

3 years ago
Assignee: nobody → bas
Flags: needinfo?(bas)
It seems that the patch in bug 1134549 fixes this.
Depends on: 1134549

Updated

2 years ago
Crash Signature: [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::vector<ots::OpenTypeCMAPSubtableRange, std::allocator<ots::OpenTypeCMAPSubtableRange> >::_Reallocate(unsigned int) ] → [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::vector<ots::OpenTypeCMAPSubtableRange, std::allocator<ots::OpenTypeCMAPSubtableRange> >::_Reallocate(unsigned int) ] [@ OOM | large | mozal&hellip;

Comment 16

2 years ago
I can no longer reproduce in Ubuntu 15.10, now that the patch referred to in comment 15 was pushed in https://hg.mozilla.org/mozilla-central/rev/3e73fc0dfb01
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.