1623221 - Large interactive SVG graph completely deadlocks Firefox

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[Mark Straver]

Attachment: perf.folded.svg

I was curious about Nightly's SVG performance so I attempted to load up a large interactive SVG graph (attached).
Result: the graph is drawn but Firefox completely deadlocks; UI unresponsive, content unresponsive, does not respond to close commands from the task bar either...

The only way to get out of it is by force-killing it from task manager.
Tested on Nightly 76.0a1 (2020-03-17) (64-bit)

The same file renders fine in Chrome, IE (a little slow), and Pale Moon.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Mark, thanks for reporting this. On my linux box, I don't see much differences between on Chrome and on Firefox. Could you please take a profile and put the link to the result?

Thank you!

Comment 2

[Mayank Bansal]

https://perfht.ml/33ptPjW with "sequential styling enabled"
Almost all the time is spent in stylo.
Emilio, mind taking a look? To repro, select one graph element at the top, then select a graph element at the very bottom.

Comment 3

[Mark Straver]

I'm on Windows. I'm sorry but taking a profile is likely not going to work because the moment I load the file, Firefox locks up. I don't even have to interact with it. I load up, and the browser locks, consumes ~30% of my 6-core CPU and is unresponsive. Taskmanager-killing is the only way out.

If you know of a way to record a profile in this situation, then please do tell.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

So that seems a different case where there's tons of stuff worth improving. In particular, that page is doing something like:

• SVGTextElement.getSubStringLength(...)
• element.style.display = "<something>"

And so on, once for each element. Seems we can potentially optimize away a lot of those flushes. But that still seems like a different thing from what Mark is seeing... Maybe file a separate bug for this? I have some ideas, though they're non-trivial because this code depends on the frame tree of all the descendants being around.

(In reply to Mark Straver from comment #3)

I'm on Windows. I'm sorry but taking a profile is likely not going to work because the moment I load the file, Firefox locks up. I don't even have to interact with it. I load up, and the browser locks, consumes ~30% of my 6-core CPU and is unresponsive. Taskmanager-killing is the only way out.

That is really odd, is that on a clean profile? One would think e10s would prevent that kind of lockup, but maybe this is a graphics issue...

Markus, do you know how to take a useful profile for something like the above? On linux I'd use perf or something but...

Mark, does this reproduce with/without WebRender and such? That would at least point to graphics code.

Comment 5

[Mark Straver]

I checked, webrender is disabled by default. enabling it makes no difference. Disabling HWA in preferences also makes no difference.
The behavior when loading from a local file is that the graph renders but the browser locks up. loading it remotely the graph only renders partially before lockup.
If I specifically end the content process that is using the most CPU, it behaves as if the tab crashed and I can resume normal operation within Firefox. It doesn't seem to be graphics related, at least not directly.

Loading the SVG, there is a brief time where the overall application process is not responding to Windows (the dreaded (not responding) suffix) but that goes away again. After that, from Windows' point of view, the process isn't locked up, but it doesn't respond to any input or window operations and uses CPU constantly; occasionally, the standard windows title bar shows before being replaced with the photon interface again after a second or so. This will go on indefinitely and Firefox doesn't recover on its own.

This is an almost-pristine profile since I only use Nightly on rare occasions to check certain features or do web compatibility research. No extensions are installed. Theme is default.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

FWIW, I tried it on my Windows laptop (thinkpad 460p, 4-core intel and Intel HD 530), it works fine.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Mark, would you mind trying to reduce the svg size to be able to take a profile? If the slowness depends on the SVG size or something like that, there should be reasonable size that is that rendering is slow but not something like a deadlock. If it doesn't depend on the size, there must be a trigger of the deadlock.

Comment 8

[Mark Straver]

I didn't create this SVG myself and I'm not aware of what tools were used to create it. I'm more than happy to provide more info if I can, but reducing the size of the SVG is likely going to be difficult.

I could potentially try a mozregression run to see if I can find a range where it starts going wrong but that will be time-consuming with lockups and I don't have time for that today, I think, and have limited time to sink into this issue unfortunately. Let me know if that would help and I'll do my best to pinpoint a regression range.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I suspect Hiro meant reducing the window size? Does that have any effect?

Comment 10

[Hiroyuki Ikezoe (:hiro)]

No I meant reducing SVG elements in the file, but reducing window size might have some effects.

Comment 11

[Mark Straver]

Reducing the window size has no effect, it will just show less of the image, but still locks up.

Comment 12

[Mark Straver]

Okay I was able to set some time aside to run mozregression -- seems it's been an issue since nightlies of Firefox 52.
Firefox 52-ESR is, however, not affected.

INFO: Last good revision: 90d8afaddf9150853b0b68b35b30c1e54a8683e7 (2016-10-19)
INFO: First bad revision: 99a239e1866a57f987b08dad796528e4ea30e622 (2016-10-20)
INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d8afaddf9150853b0b68b35b30c1e54a8683e7&tochange=99a239e1866a57f987b08dad796528e4ea30e622

Possibly bug 1310117?

Comment 13

[Mark Straver]

Attachment: reduced+profile.zip

I managed to reduce the SVG by manually cutting out <g> elements. reduced to 89k it still displays the problem, but gave me -just- enough free cycles to use devtools for recording a profile. It seems the profile is completely oblivious to any problem, though.
Both attached.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Thanks for the profile and regression range!

Here is a link to the profile result: https://perfht.ml/2vyCGDh

The result looks odd, I am seeing tons of requestAnimationFrame callbacks in the profile but there is no requestAnimationFrame calls in the SVG.

bug 1310117 is not likely the cause since IIRC at that time Stylo hadn't been enabled on nightly yet.

Comment 15

[Mark Straver]

bug 1310117 is not likely the cause since IIRC at that time Stylo hadn't been enabled on nightly yet.

That would be extra odd then, since it's something that obviously survived moving most/all of this to stylo... It just stood out to me but I'll leave the analysis up to you guys.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

Ok, so the requestAnimationFrame callbacks come from devtools, probably Mark took the profile via devtools. That makes me think that the content process didn't hang at all, the deadlock happened in the parent process or GPU process? I have no further idea what's going on there.

And I couldn't find any suspicious things in the regression range. Maybe bug 1310788 might be related to, maybe.

Mark, could you try with setting "accessibility.force_disabled" to true?

Anyways, I am setting P3 for now since this issue does rarely happen, I think.

Comment 17

[Mark Straver]

Ok, so the requestAnimationFrame callbacks come from devtools, probably Mark took the profile via devtools.

I already told you as much in comment 13...

the deadlock happened in the parent process or GPU process?

Did Firefox that far back already use a dedicated GPU process for e10s?

Mark, could you try with setting "accessibility.force_disabled" to true?

No, because it's an int ;P
Setting it to 1 or 2 solved the problem though. I don't have any special accessibility hardware or software running since I'm perfectly capable.
So the problem is e10s then?
I'm perfectly happy using this as a workaround for the time being, of course, but it still seems like a bug.

Comment 18

[Hiroyuki Ikezoe (:hiro)]

(In reply to Mark Straver from comment #17)

the deadlock happened in the parent process or GPU process?

Did Firefox that far back already use a dedicated GPU process for e10s?

Probably no.

Mark, could you try with setting "accessibility.force_disabled" to true?

No, because it's an int ;P
Setting it to 1 or 2 solved the problem though. I don't have any special accessibility hardware or software running since I'm perfectly capable.
So the problem is e10s then?

Great! Yes, this is somewhat related to E10S and accessibility stuff.

Comment 19

[Mark Straver]

Allright then.
If there is any way in which I can help with this problem since I can easily reproduce, just let me know.

Comment 20

[Jens Stutte [:jstutte]]

Hi, appears to be related to accessibility?

Comment 21

[James Teh [:Jamie]]

It seems so, yes, and it's now in the right component. Keeping p3 priority as per comment 16.

I did take a look at the profile, but I can't see anything immediately obvious.

Comment 22

[Markus Stange [:mstange]]

If this happened on a device with a touch screen, or with a connected tablet, there's a chance that bug 1687535 will help.

Comment 23

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

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 24

[James Teh [:Jamie]]

I don't know why, but this seems to be significantly better with Cache the World enabled.