943243 - Large SVG file crashes Firefox with EXCEPTION_STACK_OVERFLOW (with hundreds of nested <g transform="translate..."> elements in testcase)

Status: NEW

(Core :: Layout, defect, P3)

Description

[videoclocknet]

Attachment: B3-CLASIFICACIÓN-CASCO.pdf

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

1.- Go to http://svg-edit.googlecode.com/svn/branches/2.6/editor/svg-editor.html
2.- Click in "SVG-edit" -> "Open Image"
3.- Select the file I've attached from local machine "B3-CLASIFICACIÓN-CASCO.pdf"




Actual results:

Then Firefox crashes with no possibility of saving changes .


Expected results:

Developers are more experienced in the expected results. At the moment I'd say Firefox might not crash ;-)

In my opinion:
- Firefox could show a message explaining that the applet has crashed, keeping the rest of the content active and working
- Or it could crash only the tag in which the applet is contained, keeping the rest of the tags active

Comment 1

[videoclocknet]

Attachment: B3-CLASIFICACI_N-CASCO_.rar

Comment 2

[videoclocknet]

Sorry, I attached the wrong file. So you have to unrar the "B3-CLASIFICACI_N-CASCO_.rar" file and open the "B3-CLASIFICACI_N-CASCO_.svg" in the applet.

Regards

Comment 3

[videoclocknet]

Following are the details extracted from the Crashing Report:

AdapterDeviceID: 0x9647
AdapterVendorID: 0x1002
Add-ons: %7Bb9db16a4-6edc-47ec-a1f4-b86292ed211d%7D:4.9.21,%7Bab91efd4-6975-4081-8552-1b3922ed79e2%7D:1.0.28.1,%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D:25.0.1,es-es%40dictionaries.addons.mozilla.org:1.7,fr-dicollecte%40dictionaries.addons.mozilla.org:4.12,ca%40dictionaries.addons.mozilla.org:2.5.0,firebug%40software.joehewitt.com:1.12.5
AvailablePageFile: 5148049408
AvailablePhysicalMemory: 1794371584
AvailableVirtualMemory: 3267956736
BuildID: 20131112160018
Comments: This is the bug I've just created in Bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=943243
CrashTime: 1385454792
EMCheckCompatibility: true
Email: [e-mail]
InstallTime: 1384676668
Notes: AdapterVendorID: 0x1002, AdapterDeviceID: 0x9647, AdapterSubsysID: 358c103c, AdapterDriverVersion: 8.861.1.2000
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: release
SecondsSinceLastCrash: 2885
StartupTime: 1385451915
SystemMemoryUsePercentage: 51
Theme: classic/1.0
Throttleable: 1
TotalVirtualMemory: 4294836224
URL: http://svg-edit.googlecode.com/svn/branches/2.6/editor/svg-editor.html
Vendor: Mozilla
Version: 25.0.1
Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 : %SystemRoot%\system32\mswsock.dll 
 MSAFD Tcpip [UDP/IP] : 2 : 2 :  
 MSAFD Tcpip [RAW/IP] : 2 : 3 : %SystemRoot%\system32\mswsock.dll 
 MSAFD Tcpip [TCP/IPv6] : 2 : 1 :  
 MSAFD Tcpip [UDP/IPv6] : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD Tcpip [RAW/IPv6] : 2 : 3 :  
 RSVP TCPv6 Service Provider : 2 : 1 : %SystemRoot%\system32\mswsock.dll 
 RSVP TCP Service Provider : 2 : 1 :  
 RSVP UDPv6 Service Provider : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 RSVP UDP Service Provider : 2 : 2 :  
 MSAFD RfComm [Bluetooth] : 2 : 1 : %SystemRoot%\system32\mswsock.dll

This report also contains technical information about the state of the application when it crashed.

Comment 4

[[:Aleksej]]

(In reply to videoclocknet from comment #3)
> Following are the details extracted from the Crashing Report:

Please post the crash ID instead (which you see in about:crashes), because:

> This report also contains technical information about the state of the
> application when it crashed.




These HANG for me, with an unresponsive script (memory usage grows slowly):
* firefox-25.0.en-US.linux64  killall -ILL: bp-33854a89-6c8a-4568-b594-56e092131201  nsIFrame::GetOverflowAreas() const
* 2013-12-01-03-02-03-mozilla-central-firefox-28.0a1.en-US.linux-x86_64  killall -ILL: bp-d6dcf5ac-05eb-47cd-810f-7e1ea2131201  [@ PL_DHashTableOperate | mozilla::FramePropertyTable::Get(nsIFrame const*, mozilla::FramePropertyDescriptor const*, bool*) ]

Comment 5

[[:Aleksej]]

Attachment: The SVG to open in SVG-edit (unzip first)

(in a free cross-platform and familiar format)

Comment 6

[videoclocknet]

Ok, this is the Crash ID:
https://crash-stats.mozilla.com/report/index/0a88df4c-4ce0-4b1a-9ea9-9db0a2131201

Regards

Comment 7

[Mats Palmgren (inactive)]

The crash reason for the report in comment 6 is EXCEPTION_STACK_OVERFLOW.

Loading just the the attached SVG file directly in the browser, in a debug build:
WARNING: ProcessChildren max depth exceeded: file nsCSSFrameConstructor.cpp, line 9266
so I suspect it's very deep tree.  Don't know what happens when it's loaded in the
online SVG editor in comment 0 though; not having much luck in GDB on Linux with this.

Comment 8

[Wayne Mery (:wsmwk)]

same as, or one example of, bug 622978?

Comment 9

[videoclocknet]

I've realized this bug is much easier to reproduce: just drag and drop that file into Firefox Window and it'll automatically crash.

It doesn't matter the tag in which you drop it.

But curiously, in this last case, the crashing signature is different than the initial:

Firefox 26.0 Crash Report [@ PL_DHashTableOperate | mozilla::FramePropertyTable::Get(nsIFrame const*, mozilla::FramePropertyDescriptor const*, bool*) ]

You can read the new crashing report here:
https://crash-stats.mozilla.com/report/index/92f40190-36e0-4675-9cf3-e91f92140115

Kind Regards

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #7)
> Don't know what happens when it's loaded in the
> online SVG editor in comment 0 though; not having much luck in GDB on Linux
> with this.

Sounds like the online SVG editor is a red herring; just loading the file directly overflows the reporter's stack, per comment 9. (The crash report there is also EXCEPTION_STACK_OVERFLOW, with a similar-looking stack, aside from the fact that we got a few levels deeper before crashing.)

Comment 11

[videoclocknet]

Daniel, I'm not sure the problem resides on the file size.

After some interesting tests I've discovered the following:

1.- If I change the file extension to .html, the vector graphic is displayed correctly in Firefox
2.- If I change the file extension to .txt, the text content is displayed correctly
3.- If I change the file extension to .xml, Firefox crashes with a different signature, which is: gfx3DMatrix::TransformBounds(gfxRect const&) You can read this last crash here: https://crash-stats.mozilla.com/report/index/75a3829d-3e7b-4b11-90a4-636272140116

Regards

Comment 12

[Daniel Holbert [:dholbert]]

Not size in "number-of-bytes", but number of SVG elements to be rendered (or more likely, depth of nesting of SVG elements).

Comment 13

[videoclocknet]

Attachment: A much smaller file that also reproduces this bug

Comment 14

[Daniel Holbert [:dholbert]]

Yup, this smaller file includes hundreds of nested <g> elements, as I suspected in comment 12.

Comment 15

[videoclocknet]

> Not size in "number-of-bytes", but number of SVG elements to be rendered (or
> more likely, depth of nesting of SVG elements).

Yes, you're right. 

So, is it going to be fixed?

Comment 16

[videoclocknet]

What's the status of this?

Comment 17

[Daniel Holbert [:dholbert]]

I'm unable to reproduce (probably due to platform-specific differences in available stack memory).

But, responding to your suggested results:

(In reply to videoclocknet from comment #0)
> In my opinion:
> - Firefox could show a message explaining that the applet has crashed,
> keeping the rest of the content active and working

(Note that this isn't an applet (applet = java); this is Firefox itself, trying to render the content that it's been given)

Setting that aside though -- I'm not sure we have the ability to tell when stack memory is running out & bail out and/or warn the user; njn, do you know?

> - Or it could crash only the tag in which the applet is contained, keeping
> the rest of the tags active

Good news -- the electrolysis project [1] (for multi-process Firefox) should be able to achieve this result, and should eventually let us robustly keep issues like this one from taking down the whole browser.  This project is active, though it's no small undertaking, and it won't be in a Firefox release for months at least. (possibly years)

[1] https://wiki.mozilla.org/Electrolysis

Comment 18

[Nicholas Nethercote [inactive]]

> Setting that aside though -- I'm not sure we have the ability to tell when
> stack memory is running out & bail out and/or warn the user; njn, do you
> know?

Not that I know of :(  Stack memory usage is almost never a problem...

Comment 19

[Andrew McCreight [:mccr8]]

I think the main rule of thumb for stack memory is to give content a lower stack limit than chrome, to prevent security problems.

Comment 20

[videoclocknet]

Sorry for the nomenclature, Daniel, I was referring to executing code in general inside the browser, not to a "Java applet".

It still crashes for me in the latest build.

> I'm unable to reproduce (probably due to platform-specific differences in
> available stack memory).

The easiest way for reproducing this bug is just clicking this link: https://bugzilla.mozilla.org/attachment.cgi?id=8362291
which is the attachment of the smaller file. Just clicking it, firefox tries to show it inside the browser and it automatically crashes.

Doesn't it crash for you?

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'nsDisplayList::ComputeVisibilityForSublist':
 - nightly (version 50): 0 crash from 2016-06-06.
 - aurora  (version 49): 0 crash from 2016-06-07.
 - beta    (version 48): 61 crashes from 2016-06-06.
 - release (version 47): 157 crashes from 2016-05-31.
 - esr     (version 45): 0 crash from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          0          0
 - aurora           0          0          0          0          0          0          0
 - beta            12          6          6         11         12          6          2
 - release         25         17         16         31         23         24         12
 - esr              0          0          0          0          0          0          0

Affected platform: Windows

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'nsDisplayList::ComputeVisibilityForSublist':
 - nightly(version 50):0 crashes from 2016-06-06.
 - aurora (version 49):0 crashes from 2016-06-07.
 - beta   (version 48):68 crashes from 2016-06-06.
 - release(version 47):176 crashes from 2016-05-31.
 - esr    (version 45):1 crash from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       0       0       0       0
 - beta         11      12       7       6      11      12       6
 - release      26      25      19      16      31      23      24
 - esr           1       0       0       0       0       0       0

Affected platform: Windows

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'nsDisplayList::ComputeVisibilityForSublist':
 - nightly (version 51): 0 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 10 crashes from 2016-08-02.
 - release (version 48): 28 crashes from 2016-07-25.
 - esr     (version 45): 1 crash from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       0
 - aurora        0       0       0
 - beta          3       3       4
 - release       6       7       3
 - esr           0       0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora
 - beta              #1257
 - release #1381     #1056
 - esr