Bug 126122 - [GTK] Limit the number of tiles according to the visible area (when built without threaded compositor)
Summary: [GTK] Limit the number of tiles according to the visible area (when built wit...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Critical
Assignee: Gwang Yoon Hwang
URL: http://www.reuters.com/article/2015/0...
Keywords:
: 149037 (view as bug list)
Depends on: 155534
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-21 13:08 PST by Michael Catanzaro
Modified: 2017-02-21 08:11 PST (History)
23 users (show)

See Also:


Attachments
backtrace #1 (stopped with Ctrl+C) (77.61 KB, text/plain)
2015-01-06 12:02 PST, Michael Catanzaro
no flags Details
backtrace #2 (80.85 KB, text/plain)
2015-01-06 12:03 PST, Michael Catanzaro
no flags Details
backtrace #3 (80.14 KB, text/plain)
2015-01-06 12:03 PST, Michael Catanzaro
no flags Details
webprocess.smaps (1.75 MB, text/plain)
2015-09-13 10:15 PDT, Zan Dobersek
no flags Details
BT from gdb (30.08 KB, text/plain)
2016-02-03 00:56 PST, Andres Gomez Garcia
no flags Details
WIP (4.20 KB, patch)
2016-02-10 06:40 PST, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Patch (24.30 KB, patch)
2016-02-18 06:38 PST, Gwang Yoon Hwang
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2013-12-21 13:08:24 PST
Visiting http://www.theonion.com/ sometimes, but not always, hangs my entire desktop. My lowball guess is that this happens roughly 20% of the time.

The first warning sign is that the page is taking unusually long to load (3-4 seconds). If I react very quickly and close the tab or my browser, then the day is saved. Otherwise, I can at first move the mouse pointer very sluggishly, but not click on anything, and then I completely lose control. I have no choice but to hold the power button to shut down my computer.

I've had no success attempting to debug this, since I don't know how to trigger the bug without borking my computer.

webkitgtk3-2.2.3-1.fc20
epiphany-3.10.2-1.fc20
Comment 1 Claudio Saavedra 2014-05-14 06:16:05 PDT
So here's the thing. You are using WebKitGTK+ 2.2 which is rather old. I can reproduce this with WKGTK 2.4, but since this had not happened before to either of us, I think something buggy got into Fedora (so far all people affected report using Fedora 20) somewhere in the stack.
Comment 2 Michael Catanzaro 2014-05-14 07:23:39 PDT
I'm currently using the GNOME 3.12 copr on Fedora 20, but I've reproduced this on Arch in the past, so it's nothing Fedora-specific. I think it's been happening since the GNOME 3.8 era (so WebKitGTK+ 2.0).
Comment 3 Alberto Garcia 2014-05-15 05:54:08 PDT
Tested here (Debian) with epiphany 3.8.2-5 and webkitgtk 2.4.2-1.

I cannot reproduce the problem at all.
Comment 4 Claudio Saavedra 2014-05-16 06:33:28 PDT
I cannot reproduce this anymore after a Fedora upgrade. Both LinkedIn and The Onion work fine for me. There were mesa packages upgraded, can't pinpoint anything relevant in the changelogs though.
Comment 5 Michael Catanzaro 2014-05-16 18:38:23 PDT
Unfortunately, I can still reproduce this after the update to mesa-10.1.3-1.20140509.fc20.
Comment 6 Michael Catanzaro 2014-05-17 14:27:27 PDT
This (and Bug #126123) only seems to occur if Javascript is enabled.
Comment 7 Michael Catanzaro 2014-12-06 08:06:02 PST
*** Bug 126123 has been marked as a duplicate of this bug. ***
Comment 8 Michael Catanzaro 2015-01-06 12:02:15 PST
Here are three backtraces taken on projects.archlinux.org (where I experience the same symptoms). They all look quite similar in thread one. Stepping through the third case in gdb, I was able to successfully return to WebKit's main loop, which suggests that this may be a red herring.

I can't ever seem to reproduce it by refreshing the same page over and over, so it might only occur for new web processes, or the first time the page is loaded in the current process.
Comment 9 Michael Catanzaro 2015-01-06 12:02:50 PST
Created attachment 244084 [details]
backtrace #1 (stopped with Ctrl+C)
Comment 10 Michael Catanzaro 2015-01-06 12:03:12 PST
Created attachment 244085 [details]
backtrace #2
Comment 11 Michael Catanzaro 2015-01-06 12:03:26 PST
Created attachment 244086 [details]
backtrace #3
Comment 12 Michael Catanzaro 2015-01-06 12:07:30 PST
Also, it's a memory allocation loop (at least sometimes): WebKit was eating up ~4GiB at the time I stopped it this time, but it would have continued to rise up to the size of my physical memory before the system hangs up.
Comment 13 Joanmarie Diggs 2015-01-06 16:34:59 PST
I can sort of reproduce the Onion one with MiniBrowser built from master, on Fedora 21, using Mesa 10.4.x. The "sort of" is because I see a significant delay when the page loads, and if I interrupt loading the backtrace looks quite similar to what is in comment 9. BUT if I wait long enough, the page loads. And my desktop does not hang. Is it definitely a hang, or if you walk away and make a sandwich, do you find things back to normal upon your return?

As for the backtraces in comment 10 and comment 11: Are those from the Onion? Or are they from pages with select elements? And if the latter, is the problem seen primarily when there are a bunch of options in a given select element? And if so to that, if you do the make-a-sandwich test, does the problem eventually go away or is it a proper hang?
Comment 14 Michael Catanzaro 2015-01-06 19:33:01 PST
(In reply to comment #13)
> I can sort of reproduce the Onion one with MiniBrowser built from master, on
> Fedora 21, using Mesa 10.4.x. The "sort of" is because I see a significant
> delay when the page loads, and if I interrupt loading the backtrace looks
> quite similar to what is in comment 9. BUT if I wait long enough, the page
> loads.

Often there is a significant delay, but the browser recovers and completes the load. When the load completes, I can look in System Monitor and see that I have one web process using 3.4 GiB of memory, the rest with 40 MiB apiece. I think that when the browser does not recover within a reasonable amount of time, it has simply allocated something much more than 3 GiB and begun swapping.

> And my desktop does not hang. Is it definitely a hang, or if you walk
> away and make a sandwich, do you find things back to normal upon your return?

It does recover after a "sandwich," but it's very slow when I return (e.g. unlocking the computer takes ~5s, launching any application takes ~15s) and the desktop will regularly hang for ~5s intervals. I think this is just swapping.

(In reply to comment #13)
> As for the backtraces in comment 10 and comment 11: Are those from the
> Onion? 

No:

(In reply to comment #8)
> Here are three backtraces taken on projects.archlinux.org (where I
> experience the same symptoms).

If you think that is a different bug, I can reopen bug #126123, but I hope they're the same. The Onion is worse for testing because it reloads itself (probably to trick its advertisers into thinking it gets more page views than it really does) and it's not fun when I forget and a background tab triggers the bug.

> Or are they from pages with select elements? And if the latter, is
> the problem seen primarily when there are a bunch of options in a given
> select element? 

Yes, that must be it, good call! projects.archlinux.org has a huge combo box in the upper right that I never noticed until you suggested I look for select elements. bugzilla.redhat.org has one as well. These are well-known to perform horrendously (I use Firefox when I need to change a Component on bugzilla.redhat.com).

I don't see one on the Onion, though.
Comment 15 Joanmarie Diggs 2015-01-08 03:36:32 PST
So I see that you've changed the summary to reflect the combo box issue. Before the summary stated that the problem is on the Onion's site which lacks combo boxes. Were it me, I'd probably split this into two bugs because, well, it's two bugs. ;) See your backtraces.
Comment 16 Michael Catanzaro 2015-01-08 04:53:29 PST
You're right, I'm just causing more confusion.
Comment 17 Michael Catanzaro 2015-06-30 15:13:26 PDT
Possibly bug #139847
Comment 18 Michael Catanzaro 2015-09-09 18:02:05 PDT
This bug has become a bit confused, due to the various web sites studied in the past:

theonion.com, which no longer seems to exhibit this issue
www.archlinux.org/packages, ditto
bugzilla.redhat.com, still a big problem, but not a reliable reproducer

A user recently found a site that reproduces this reliably: [1]

Let's repurpose this bug to cover just the site where we can reproduce this reliably. If it happens to be that the bug still exists on other sites after we have fixed it on this on, we can open different bugs.

***Warning*** clicking the link below will hang your computer unless you are prepared to immediately kill your web process.

[1] http://www.reuters.com/article/2015/09/02/us-iran-nuclear-congress-idUSKCN0R21L620150902
Comment 19 Zan Dobersek 2015-09-13 10:15:05 PDT
Created attachment 261082 [details]
webprocess.smaps
Comment 20 Zan Dobersek 2015-09-13 10:15:40 PDT
At least on the Reuters page the DRM allocator nodes appear to be leaked, resulting in an OOM.

From attached webprocess.smaps,

    cat webprocess.smaps | grep "drm mm object"

yields ~2700 such entries, each 4MB in size, or >10GB in total (at ~11GB consumption).

No idea about the why.
Comment 21 Michael Catanzaro 2015-09-24 17:07:01 PDT
A Radeon user reports it crashes the driver:

[drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -12

But presumably that's a symptom of the leak.
Comment 22 Jeff Fortin 2015-10-27 13:51:21 PDT
I've been experiencing this problem with LinkedIn recently when accepting invitations to connect (when clicking the button)... FWIW / adding some precision to the previous mention of LinkedIn by someone else.
Comment 23 Michael Catanzaro 2015-11-20 05:13:18 PST
Similar issue on www.vondafone.es.
Comment 24 Michael Catanzaro 2016-01-29 06:23:21 PST
*** Bug 149037 has been marked as a duplicate of this bug. ***
Comment 25 Michael Catanzaro 2016-01-29 06:27:33 PST
Another similar issue:

"""
Then, from the top bar I place my pointer over the "Connections" menu so it is expanded, once expanded, I click on the "See all" link:
https://www.linkedin.com/people/pymk/hub?ref=global-nav&trk=nav_utilities_invites_header

Upon doing so, the browser freezes and I notice the HD of my computer starting to work hard. After checking with "top" the WebKitWebProcess is growing its used memory by the Gbs!!! and it doesn't seem to stop.

This may not be a problem in WKGTK+ but the graphics driver since, after repeating the process with a GDB attached to the WebKitWebProcess, GDB states that the point in which it exits when manually killing the process is:
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so
"""
Comment 26 Michael Catanzaro 2016-01-29 06:33:08 PST
Er, that's on LinkedIn; didn't paste quite enough from the original bug ;)
Comment 27 Michael Catanzaro 2016-01-29 07:15:48 PST
Andres and I can both reproduce the issue reliably on LinkedIn.
Comment 28 Alberto Garcia 2016-02-01 00:28:29 PST
Can you also reproduce the problem with this one?

http://www.reuters.com/article/2015/10/18/us-new-york-flightcenter-idUSKCN0SC14B20151018

There's a release-critical bug in Debian because of this URL.

https://bugs.debian.org/802380
Comment 29 Carlos Alberto Lopez Perez 2016-02-01 04:56:56 PST
You can reproduce this without killing your desktop by using Linux's cgroups to limit the amount of memory that webkit can use. This way is easier to reproduce and test:

$ sudo cgcreate -g memory:/testwebkitmem
$ echo $(( 1 * 1024 * 1024 * 1024 ))| sudo tee /sys/fs/cgroup/memory/testwebkitmem/memory.limit_in_bytes
$ echo $(( 2 * 1024 * 1024 * 1024 ))| sudo tee /sys/fs/cgroup/memory/testwebkitmem/memory.memsw.limit_in_bytes
$ sudo cgexec -g memory:/testwebkitmem sudo -H -u $USER Tools/jhbuild/jhbuild-wrapper --gtk run ./WebKitBuild/Release/bin/MiniBrowser http://www.reuters.com/article/us-new-york-flightcenter-idUSKCN0SC14B20151018

So, I quickly get WebKitWebProcess killed by the kernel's OOM-killer:

Task in /testwebkitmem killed as a result of limit of /testwebkitmem
memory: usage 1048576kB, limit 1048576kB, failcnt 72526
memory+swap: usage 1967216kB, limit 2097152kB, failcnt 0
kmem: usage 0kB, limit 18014398509481983kB, failcnt 0
Memory cgroup stats for /testwebkitmem: cache:3480KB rss:1045096KB rss_huge:0KB mapped_file:3476KB writeback:285804KB swap:918640KB inactive_anon:524344KB active_anon:524192KB inactive_file:0KB active_file:0KB unevictable:0KB
[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
[17018]     0 17018    13843      806      31      120             0 sudo
[17019]     0 17019    13843        0      29      120             0 sudo
[17020]  1000 17020   515762    18778     226     6572             0 MiniBrowser
[17040]  1000 17040   775055    15724     312     6776             0 WebKitNetworkPr
[17042]  1000 17042  1085848   209041    1182   288385             0 WebKitWebProces
Memory cgroup out of memory: Kill process 17042 (WebKitWebProces) score 951 or sacrifice child
Killed process 17042 (WebKitWebProces) total-vm:4343392kB, anon-rss:752824kB, file-rss:83340kB


But, this doesn't kills or causes any instability on my system, so is a nice trick to debug memory problems.

My 2 cents.
Comment 30 Carlos Alberto Lopez Perez 2016-02-01 05:01:27 PST
(In reply to comment #28)
> Can you also reproduce the problem with this one?
> 
> http://www.reuters.com/article/2015/10/18/us-new-york-flightcenter-
> idUSKCN0SC14B20151018
> 
> There's a release-critical bug in Debian because of this URL.
> 
> https://bugs.debian.org/802380

I have uploaded a copy of the page here http://people.igalia.com/clopez/wkbug/126122/rnyc/ just in case it gets modified or made unavailable.

I get an OOM issue with this website (as also with the copy I made)
Comment 31 Michael Catanzaro 2016-02-01 07:51:09 PST
Thanks for the neat cgroups suggestion and for taking the backup, Carlos!

My less-refined way to test this safely is to type 'killall WebKitWebProcess' in my terminal, open system monitor, and kill it before it gets out of hand, but that's pretty risky....

(In reply to comment #28)
> Can you also reproduce the problem with this one?
> 
> http://www.reuters.com/article/2015/10/18/us-new-york-flightcenter-
> idUSKCN0SC14B20151018

Yes, on the first try.
Comment 32 Michael Catanzaro 2016-02-01 07:52:03 PST
FWIW we've now documented this problem on Intel, Nvidia, and AMD graphics.
Comment 33 Carlos Alberto Lopez Perez 2016-02-01 08:27:13 PST
(In reply to comment #32)
> FWIW we've now documented this problem on Intel, Nvidia, and AMD graphics.

This is happening also on my laptop with the NVIDIA proprietary drivers. I don't see any artifacts on the screen, I just get into an OOM situation
Comment 34 Andres Gomez Garcia 2016-02-03 00:56:53 PST
Created attachment 270564 [details]
BT from gdb

I'm using WebKitGtk+ with my own JHBuild setting:
https://github.com/tanty/jhbuild-epiphany/tree/master

Epiphany 3.18.0 and WebKit 2.10.7

I'm running Epiphany with the dconf key:

"process-model" = "shared-secondary-process"

Attached, a backtrace stopped when the memory is exponentially increasing.
Comment 35 Andres Gomez Garcia 2016-02-03 00:57:22 PST
(In reply to comment #34)
> Created attachment 270564 [details]
> BT from gdb
> 
> I'm using WebKitGtk+ with my own JHBuild setting:
> https://github.com/tanty/jhbuild-epiphany/tree/master
> 
> Epiphany 3.18.0 and WebKit 2.10.7
> 
> I'm running Epiphany with the dconf key:
> 
> "process-model" = "shared-secondary-process"
> 
> Attached, a backtrace stopped when the memory is exponentially increasing.

For the URL: http://people.igalia.com/clopez/wkbug/126122/rnyc/
Comment 36 Andres Gomez Garcia 2016-02-03 08:35:40 PST
I can confirm this is not reproducible (with any of the listed links in this report) with WebKitGtk+ from my own JHBuild setting:
https://github.com/tanty/jhbuild-epiphany/tree/master

WebKit 2.10.7, using MiniBrowser, and passing the CMake arg: -DENABLE_OPENGL=OFF
Comment 37 Andres Gomez Garcia 2016-02-03 09:38:07 PST
I can confirm this IS REPRODUCIBLE with WebKitGtk+ from my own JHBuild setting:
https://github.com/tanty/jhbuild-epiphany/tree/master

WebKit 2.10.7, using MiniBrowser, and passing the CMake arg: -DUSE_REDIRECTED_XCOMPOSITE_WINDOW=OFF
Comment 38 Carlos Garcia Campos 2016-02-03 09:40:58 PST
(In reply to comment #37)
> I can confirm this IS REPRODUCIBLE with WebKitGtk+ from my own JHBuild
> setting:
> https://github.com/tanty/jhbuild-epiphany/tree/master
> 
> WebKit 2.10.7, using MiniBrowser, and passing the CMake arg:
> -DUSE_REDIRECTED_XCOMPOSITE_WINDOW=OFF

Thanks!, so this time I can't blame the redirected window :-P
Comment 39 Carlos Garcia Campos 2016-02-05 05:48:00 PST
OK, I've been debugging this and I know what the problem is. In the case of the test case saved by Carlos Lopez, we have a layer of size 12000079x525, which is huge. The tiled backing store (TextureMapperTiledBackingStore) creates tile for the whole layer bounds, which means ~6000 tiles of 2000x525. If I'm understanding the code correctly, the tiled backing store is not taking into account the visible area at all. This is a problem for huge layers, but even for the case of smaller layers, we might be wasting the memory and cpu computing tiles that are offscreen. So, I think the tiled backing store should build a coverage area based on the visible size, and create tiles only for that area. I've noticed that texmap/coordinated/TiledBackingStore does that, so I wonder if we could somehow reuse the code or have a common tile manager that could be used by both backing stores. I'm not a graphics expert, so I hope that someone with more experience could help here now that we know what the problem is, otherwise I'll try to do it myself and any help would be really appreciated.
Comment 40 Carlos Garcia Campos 2016-02-10 06:40:30 PST
Created attachment 270986 [details]
WIP

This is just an experiment, I don't think it's the right solution, but could work as a workaround. The idea is basically to provide the visible rectangle to the texture mapper, and never create tiles that don't intersect with the visible rect.
Comment 41 Carlos Alberto Lopez Perez 2016-02-11 18:41:49 PST
Not directly related with this bug, but I guess is interesting info anyway:

I'm not longer able to reproduce this problem if I force AC mode to be off. The usage of RAM don't grows out of normal. I have uploaded a patch to bug 154147 that allows to do this by just setting an environment variable before running the browser.
Comment 42 Gwang Yoon Hwang 2016-02-18 06:38:11 PST
Created attachment 271659 [details]
Patch
Comment 43 Gwang Yoon Hwang 2016-02-18 06:44:37 PST
As cgarcia mentioned, this whole problem happened because of the out-dated TextureMapperBackingStore. I modified it to use basic concepts of the visible rect and coverage area when creating tiles at the TextureMapperBackingStore, instead of replacing it with a TiledBackingStore.
Because there is some difference between the coordinated graphics and the GTK's texture mapper while handling scrolling and bitmap buffers.
Comment 44 Carlos Garcia Campos 2016-02-18 22:37:51 PST
Comment on attachment 271659 [details]
Patch

Awesome patch, thank you very much!
Comment 45 WebKit Commit Bot 2016-02-18 23:27:25 PST
Comment on attachment 271659 [details]
Patch

Clearing flags on attachment: 271659

Committed r196803: <http://trac.webkit.org/changeset/196803>
Comment 46 WebKit Commit Bot 2016-02-18 23:27:34 PST
All reviewed patches have been landed.  Closing bug.
Comment 47 Zan Dobersek 2016-02-19 00:23:34 PST
Comment on attachment 271659 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=271659&action=review

> Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:652
> +void GraphicsLayerTextureMapper::markVisibleRectAsDirty()
> +{
> +    m_isVisibleRectDirty = true;
> +
> +    if (maskLayer())
> +        downcast<GraphicsLayerTextureMapper>(*maskLayer()).markVisibleRectAsDirty();
> +    if (replicaLayer())
> +        downcast<GraphicsLayerTextureMapper>(*replicaLayer()).markVisibleRectAsDirty();
> +    for (auto* child : children())
> +        downcast<GraphicsLayerTextureMapper>(*child).markVisibleRectAsDirty();
> +}

This is wasteful. It would be more efficient to set up a state object during the layer flushing, copy it for every layer and update the 'is-visible-rect-dirty' parameter by or-ing the m_isVisibleRectDirty value into it, and then pass it to every child.

> Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:663
> +bool GraphicsLayerTextureMapper::selfOrAncestorHasActiveTransformAnimation() const
> +{
> +    if (m_animations.hasActiveAnimationsOfType(AnimatedPropertyTransform))
> +        return true;
> +
> +    if (!parent())
> +        return false;
> +
> +    return downcast<GraphicsLayerTextureMapper>(*parent()).selfOrAncestorHasActiveTransformAnimation();
> +}

This too could be included in that state object, removing the need to go back up the layer tree to find a parent with any active animation.

> Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:682
> +    m_layerTransform.combineTransforms(parent() ? downcast<GraphicsLayerTextureMapper>(*parent()).m_layerTransform.combinedForChildren() : TransformationMatrix());

combineTransforms() could only be called if parent() exists, no?
Comment 48 Csaba Osztrogonác 2016-02-19 04:01:31 PST
(In reply to comment #45)
> Comment on attachment 271659 [details]
> Patch
> 
> Clearing flags on attachment: 271659
> 
> Committed r196803: <http://trac.webkit.org/changeset/196803>

It broke the WinCairo build, cc-ing port maintainters.
Comment 49 Michael Catanzaro 2016-02-19 10:31:39 PST
It would be really nice to get an EWS for WinCairo.

[118/129] Building CXX object Source\WebKit\CMakeFiles\WebKit.dir\win\WebCoreSupport\AcceleratedCompositingContext.cpp.obj
FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP /DWIN32 /D_WINDOWS /W4 /GR- /EHs- /EHc-   /MT /Zi /Ob0 /Od /RTC1 -IDerivedSources\ForwardingHeaders -IDerivedSources -I..\..\WebKitLibraries\win\include -I..\..\Source\WebKit\WebCoreSupport -I. -I..\..\Source -IDerivedSources\ForwardingHeaders\JavaScriptCore -IDerivedSources\ForwardingHeaders\WebCore -IDerivedSources\ForwardingHeaders\WebKitLegacy -I..\..\WebKitLibraries\win\include\cairo -I..\..\WebKitLibraries\win\include\sqlite -I..\..\Source\WebCore\platform\graphics\cairo -I..\include\private -I..\include\private\JavaScriptCore -I..\include\private\WebCore -I..\..\Source\WebKit\Storage -I..\..\Source\WebKit\win -I..\..\Source\WebKit\win\plugins -I..\..\Source\WebKit\win\WebCoreSupport -I..\..\Source\WebKit\WebKit.vcxproj\WebKit -I..\..\Source\WebKit\.. -IDerivedSources\WebKit\include -IDerivedSources\WebKit\Interfaces -IDerivedSources\ForwardingHeaders\ANGLE -IDerivedSources\ForwardingHeaders\ANGLE\include -IDerivedSources\ForwardingHeaders\ANGLE\include\egl -IDerivedSources\ForwardingHeaders\ANGLE\include\khr -IDerivedSources\WebKit    /wd4018 /wd4068 /wd4099 /wd4100 /wd4127 /wd4138 /wd4146 /wd4180 /wd4189 /wd4201 /wd4244 /wd4251 /wd4267 /wd4275 /wd4288 /wd4291 /wd4305 /wd4309 /wd4344 /wd4355 /wd4389 /wd4396 /wd4456 /wd4457 /wd4458 /wd4459 /wd4481 /wd4503 /wd4505 /wd4510 /wd4512 /wd4530 /wd4610 /wd4611 /wd4702 /wd4706 /wd4800 /wd4819 /wd4951 /wd4952 /wd4996 /wd6011 /wd6031 /wd6211 /wd6246 /wd6255 /wd6387 /Zi /GS /EHa- /EHc- /EHs- /fp:except- /analyze- /bigobj /Gy- /openmp- /GF- /Yu"WebKitPrefix.h" /FI"WebKitPrefix.h" /Fp"C:/Users/Alex/Documents/WinCairoBot/win-cairo-release/build/WebKitBuild/Release/Source/WebKit/WebKitPrefix.pch" /showIncludes -DBUILDING_WITH_CMAKE=1 -DFRAMEWORK_NAME=WebKit -DHAVE_CONFIG_H=1 -DNOMINMAX -DUNICODE -DUSE_CAIRO=1 -DUSE_CURL=1 -DWEBKIT_EXPORTS -DWEBKIT_EXPORTS=1 -DWINVER=0x601 -DWTF_PLATFORM_WIN_CAIRO=1 -DWebKit_EXPORTS -D_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=1 -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_UNICODE -D_WINDOWS /FoSource\WebKit\CMakeFiles\WebKit.dir\win\WebCoreSupport\AcceleratedCompositingContext.cpp.obj /FdSource\WebKit\CMakeFiles\WebKit.dir\ /FS -c ..\..\Source\WebKit\win\WebCoreSupport\AcceleratedCompositingContext.cpp
..\..\Source\WebKit\win\WebCoreSupport\AcceleratedCompositingContext.cpp(363): error C2660: 'WebCore::GraphicsLayerTextureMapper::updateBackingStoreIncludingSubLayers': function does not take 0 arguments
ninja: build stopped: subcommand failed.
Comment 50 Michael Catanzaro 2016-02-19 10:32:28 PST
Reopening due to the build break and the review comments from Zan.
Comment 51 Csaba Osztrogonác 2016-02-22 02:25:38 PST
(In reply to comment #49)
> It would be really nice to get an EWS for WinCairo.

The WinCairo port and its buildbot isn't maintained well,
nobody fixes build breaks, bot issues day by day. I don't
think if somebody is interested in maintaining an EWS too.
Comment 52 Alex Christensen 2016-02-22 11:27:19 PST
peavo fixed WinCairo in https://bugs.webkit.org/show_bug.cgi?id=154545
Comment 53 Michael Catanzaro 2016-02-22 11:37:15 PST
OK, you can use another bug to address Zan's review comments, if you have time.
Comment 54 WebKit Commit Bot 2016-03-16 00:00:29 PDT
Re-opened since this is blocked by bug 155534
Comment 55 Carlos Alberto Lopez Perez 2016-03-16 06:49:15 PDT
This was rolled out in <http://trac.webkit.org/changeset/198266>


Which sites did it break???
Comment 56 Michael Catanzaro 2016-03-16 06:56:29 PDT
Notably Twitter, see bug #155426
Comment 57 Michael Catanzaro 2016-03-20 08:15:00 PDT
(In reply to comment #55)
> This was rolled out in <http://trac.webkit.org/changeset/198266>
> 
> 
> Which sites did it break???

This also (probably) caused: bug #155059, bug #154879
Comment 58 Michael Catanzaro 2016-03-29 09:40:56 PDT
Today's complaint: "so a friend sent me a link to a tweet that froze my computer for 5 minutes :P"

I've seen enough circumstantial evidence of this that I'm now fairly confident that the set of sites broken by this commit are the same as the set of sites that suffer from this issue.
Comment 59 Andres Gomez Garcia 2016-05-16 03:02:24 PDT
This seems to trigger also this bug:
http://es.gizmodo.com/spacex-contrata-al-creador-de-los-disfraces-de-marvel-y-1774740059
Comment 60 Michael Catanzaro 2016-08-01 07:01:53 PDT
*** Bug 160402 has been marked as a duplicate of this bug. ***
Comment 61 Michael Catanzaro 2016-08-03 09:49:47 PDT
Carlos says issue is fixed in threaded compositor; we're keeping it open until we remove the ability to build without threaded compositor, but I guess it's not a priority anymore (Yoon).
Comment 62 Michael Catanzaro 2016-10-14 08:57:10 PDT
(In reply to comment #61)
> we're keeping it open until we remove the ability to build without threaded compositor

So, can we do this? It seems to be working fine, right?

Or: is this bug still an issue when WEBKIT_DISABLE_COMPOSITING_MODE is used?
Comment 63 Carlos Garcia Campos 2016-10-14 09:00:27 PDT
(In reply to comment #62)
> (In reply to comment #61)
> > we're keeping it open until we remove the ability to build without threaded compositor
> 
> So, can we do this? It seems to be working fine, right?

No, we don't have enough feedback yet, it might be broken in some particular gpus, for example.

> Or: is this bug still an issue when WEBKIT_DISABLE_COMPOSITING_MODE is used?

No, it only happens with AC on.
Comment 64 Karlen Simonyan 2016-12-20 06:04:44 PST
One of the real-world examples of this bug is TypeScript Playground (https://www.typescriptlang.org/play/), which hosts Monaco editor.

Crashing with AC on.

--------------------------------------------------------
System: Win 10.
Webkit r209238. 
Cairo v1.14.4
Graphics: Intel® HD Graphics 4400; nVidia GeForce 750 M
--------------------------------------------------------

Patch (https://bugs.webkit.org/attachment.cgi?id=271659) helps to resolve the issue partially: some tiles remain uninitialzed (i.e. non-intersected).

Just try to scroll a sample on TypeScript Playground's page.

Moreover, GitHub is being affected: single-file pages are rendering huge tables, which require tiles to be preinitialized.

For example, try to open (https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/graphics/texmap/coordinated/TiledBackingStore.cpp).
Comment 65 Michael Catanzaro 2016-12-20 06:47:30 PST
Karlen, did you build WebKit with -DENABLE_THREADED_COMPOSITOR=OFF?

This issue has kinda dropped off the roadmap because that is a non-default configuration.
Comment 66 Karlen Simonyan 2016-12-20 08:12:56 PST
Hi Michael,

Yes without threaded compositor feature enabled, so texmap/TextureMapperTiledBackingStore is being used instead of texmap/coordinated/TiledBackingStore.
Comment 67 Michael Catanzaro 2017-02-20 15:05:19 PST
texmap/TextureMapperTiledBackingStore is removed in bug #168606, so this can be closed now.
Comment 68 Michael Catanzaro 2017-02-21 07:51:59 PST
Nope, I must have misread the patch. Looks like it's still around if ENABLE_OPENGL=OFF.

I think we should remove support for ENABLE_OPENGL=OFF if nobody fixes this bug.
Comment 69 Carlos Garcia Campos 2017-02-21 08:11:07 PST
No, if opengl is disabled we don't have accelerated compositing