1317730 - [e10s] Freeze website

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[pawel]

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20161115030213

Steps to reproduce:

Hello I would ask about this website .When I opened this website my Firefox stop working.

http://www.canard.gitd.gov.pl/cms/o-nas/mapa-urzadzen

Comment 1

[Alice0775 White]

I can reproduce the hang.
https://hg.mozilla.org/mozilla-central/rev/5e76768327660437bf3486554ad318e4b70276e1
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 ID:20161115030213

Disabling e10s or non-e10s window seems to fix the hang.

Comment 2

[Alice0775 White]

Steps to reproduce:
1. Open http://www.canard.gitd.gov.pl/cms/o-nas/mapa-urzadzen
2. Wait for 20-30sec
3. Try to interact with the web pages

Actual Results:
Web page does not respond.
Close button does not respond.

Comment 3

[pawel]

Firefox 53.0a1 Crash Report [@ IPCError-browser | ShutDownKill ]




https://crash-stats.mozilla.com/report/index/55d5eca0-330c-4d35-9600-4c8f72161116

Comment 4

[Ryan VanderMeulen [:RyanVM]]

A regression window and a hang stack (by forcing a Firefox crash) would be useful here.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

I caught this is Visual Studio. Gives a stack like

[External Code]	
xul.dll!D3DVsyncSource::D3DVsyncDisplay::VBlankLoop() Line 1877	C++
xul.dll!mozilla::detail::RunnableMethodImpl<enum nsresult (__cdecl nsMemoryReporterManager::*)(void) __ptr64,1,0>::Run() Line 812	C++
xul.dll!MessageLoop::DoWork() Line 429	C++
xul.dll!base::MessagePumpDefault::Run(base::MessagePump::Delegate * delegate) Line 36	C++
xul.dll!base::Thread::ThreadMain() Line 180	C++
xul.dll!`anonymous namespace'::ThreadFunc(void * closure) Line 29	C++
[External Code]

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Would still be nice to get a regression window on this if possible.

Comment 7

[Alice0775 White]

At least, the hang is reproduced since 27.0a1 BuildID=20131021030203 if e10s is force enabled

Comment 8

[Ryan VanderMeulen [:RyanVM]]

I bisected this down to some time in the April/May 2013 timeframe when the browser.tabs.remote pref first started actually working (as in, plugin-container was actually doing things instead of sitting there while the parent process did all the work). Bug 697319 looks probably relevant in that respect. So basically I'm calling this "since ever" as far as e10s is concerned.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Seems unlikely we're going to get a fix for this in time for 51 at this point. Would still be nice if we could get it fixed for 52.

Comment 10

[pawel]

Yes I agree.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Mason, can you reproduce this, and given comment 5, does it make sense for vsync to be involved?

Comment 12

[Mason Chang [Inactive] [:mchang]]

(In reply to Milan Sreckovic [:milan] from comment #11)
> Mason, can you reproduce this, and given comment 5, does it make sense for
> vsync to be involved?

I just tried on today's nightly and could not reproduce. I can reproduce on 51. I doubt it's vsync in this case since we haven't touched that code for a while. Vsync is at the bottom of every stack since that's what triggers when we do things. See the [External Code] from comment 5. Vsync is probably just calling the external code and it's dying somewhere else in the stack.

Comment 13

[Mason Chang [Inactive] [:mchang]]

Does this still reproduce on 54 nightly for you?

Comment 14

[pawel]

No works fine.

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's reopen if we find it happening again.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

ni? myself to try to bisect the fix here so we can make a decision about what to do for 52/53.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Fix range from mozregression: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1fd906e69d3572e0f37a16e3ffee139a7b952096&tochange=ed256c5c7d23638dfd1d29cf1c5eb6c0df7d4864

-> Fixed by bug 1319744. Which fits the symptoms I observed in that it's locking up when pulling a lot of resources from the network and trying to place all the blue markers on the map.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

I've confirmed that applying the patch from bug 1319744 to mozilla-beta makes the hangs go away there too. I'll try to get it uplifted!

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Confirmed fixed in recent CI builds off mozilla-beta as well. This fix will ship in Fx54b4 tomorrow.