Issue metadata
Sign in to add a comment
|
Chrome 64 introduced a severe per-tab memory leak when playing Granblue Fantasy that can eventually produce crashes
Reported by
k...@luminance.org,
Feb 9 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Steps to reproduce the problem: 1. Play Granblue Fantasy on the normal detail mode (the 'Lite' mode runs different, simpler game code that does not seem to reproduce the memory leak) 2. Visit the home page ( http://game.granbluefantasy.jp/#mypage ) 3. Click the 'Home' button on the bottom navigation bar repeatedly What is the expected behavior? Memory usage should remain relatively stable What went wrong? Memory usage increases by approximately 40mb every page navigation. Memory usage does not drop if you hard reload the tab or navigate away. The only way to release the memory is to fully close the tab. Crashed report ID: no How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? Yes Chrome 63 Chrome version: 64.0.3282.140 (Official Build) (64-bit) Channel: stable OS Version: 10.0 Flash Version: I did some testing and using a heap snapshot in the developer tools does not show much JS heap usage (around 60-100mb depending on page). Gameplay pages are also hosed in an extra way: The GPU process begins to leak memory at an alarming rate, though not quite in the same fashion. I've seen it hit 1GB on its own and take quite a while to release any of that memory, and it only eventually settles in at 500MB (not the 100mb or so it is without the game open, and an obscenely large number to begin with) I've managed to get the game tab up to 2gb of memory, at which point it crashes if you do much to it. If I try to take a heap snapshot at that point the tab quickly allocates another 2gb of memory and falls over. Leaving the tab idle on the game's home page does not produce any memory leak. With the tab at around 800mb of memory usage, the developer tools' 'Performance' tab only reports HEAP of 208mb. The 'Collect Garbage' button in developer tools does nothing. Many players use my Chrome extension while playing this game but I've verified that the extension is unrelated - this game leaks in Chrome 64 without any extensions enabled. This issue is widely discussed by players and it appears many of them are force-installing Chrome 63 and disabling updates, or switching to other Blink-based browsers like Vivaldi. You can see some of the reports here: https://www.reddit.com/r/Granblue_en/comments/7wc4w5/chromes_latest_version_breaks_granblue_memory/ Playing this game requires an account, but I think you can get through the tutorial and to the home page without too much fuss. Parts of the early UI are in Japanese but the rest of it has a full English localization you can turn on.
,
Feb 9 2018
,
Feb 9 2018
,
Feb 9 2018
Is there a way to trace memory allocations? I looked through the categories in the tracer and didn't find anything. If not, which categories should I trace?
,
Feb 9 2018
I am able to reproduce in Chrome 64.0.3282.140. Issue seems fixed in top-of-tree (Chrome 66)
,
Feb 9 2018
I was mislead in comment #5. What is actually happening is that the bug is reproducible in Chrome (Official) builds but not in Chromium (open source) release builds builds. I also noticed that there is no sound when playing in a Chromium build. My best guess is that the leak is coming from a closed source codec that only ships in official builds. Tentatively triaging as an Audio bug.
,
Feb 9 2018
Adding memory infra component so someone can answer #4
,
Feb 9 2018
,
Feb 9 2018
Re: comment #6 it's possible this is an audio issue - the game's 'Lite' mode (which does not leak) disables sound, while the other modes have it on by default. If I mute the game (click the music note in the top left) while in non-Lite mode, the leak is dramatically reduced but not gone - it's about 10-20mb per reload vs 40mb if unmuted. I should note that it's still leaking in either case, though - maybe the game still preloads some audio assets even if muted and every sound it's loading is leaking?
,
Feb 10 2018
http://luminance.org/stuff/810701/audio-leak.html seems to reliably reproduce the issue *as long as* you sequentially issue an xhr, then click decode, then click play. It's playing one of the MP3 files from the game's homepage but I suspect the actual file doesn't matter. The XHRs come back from disk cache but still eat up memory for the result (expected, I guess), but that memory is eventually GCd if you just mash the XHR button. So it's (as I'd expect) not the XHR itself. The decode button makes a copy of the XHR result (though this costs nothing and doesn't allocate, presumably because v8 arraybuffers are copy-on-write or something), then passes it to decodeAudioBuffer. This also... doesn't allocate? The decoded buffer is stored. The play button then creates a buffersourcenode and gainnode against the most recently decoded buffer, and starts it. The node is stored also. For some reason the combination of doing all 3 of those things in sequence reproduces the leak, but if I issue a single XHR and decode multiple times, or decode once and play multiple times, the memory usage barely climbs at all. If I reproduce the leak by hitting all 3 buttons in sequence the memory is not freed on page reload or navigation.
,
Feb 12 2018
Able to reproduce the issue using #64.0.3282.140 on Mac 1013.3, Win 10 and Linux Ubuntu 14.04 as per the steps mentioned below. Steps followed: 1. Launch Browser 2. Open Chrome task manager 3. Navigate to http://luminance.org/stuff/810701/audio-leak.html 4. Click on issue an xhr, then click decode, then click play (Do the same for 3 times) 5. Refresh the page 6. Observe the memory is not freed on page reload. (Please find the screencast) Bisect info =========== Good Build: 64.0.3282.30 Bad Build: 64.0.3282.31 CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/64.0.3282.30..64.0.3282.31?pretty=fuller&n=10000 https://chromium.googlesource.com/chromium/src/+/e8ae5e184fe20c2e0615234ab493c6c889c3241d Review ON: https://chromium-review.googlesource.com/826912 @yukishiino-- Could you please look into the issue, and help us in re-assigning to correct owner if this is not related to your change. Thanks!!
,
Feb 12 2018
,
Feb 12 2018
kg@luminance.org: has there been any client side changes to address this issue? I tried recreating this today and seems to be okay now?
,
Feb 13 2018
I don't know whether they've made any client side game code changes, they push updates pretty frequently. Make sure you have the game unmuted so it's playing music on the home screen.
,
Feb 13 2018
re #c11, I understand that my CL triggered (or looks like having triggered) the issue, so it's somewhat relevant. However, I'm not yet sure if this really caused this issue. As I tested it with ToT (including my patch), the issue does not reproduce while I can reproduce the issue with M64 stable. That's strange. And the page reload should release everything basically, and my CL doesn't look like relevant to page reload. Anyway, I'll take a deeper look tomorrow.
,
Feb 13 2018
@#15 While testing a ToT build, remember that it has to be a "is_chrome_branded = true" build. Otherwise the bug won't repro.
,
Feb 13 2018
M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Feb 14 2018
,
Feb 14 2018
Re #c16: The issue reproduces without "is_chrome_branded=true" and it looks to me nothing to do with the issue. I confirmed that, regardless of "is_chrome_branded=true", - The issue doesn't repro on ToT (which includes my patch). - The issue reproduces on M64. - The issue reproduces at e8ae5e184fe20c2e0615234ab493c6c889c3241d (right after my patch). - The issue doesn't repro at 5ed4257ef11ec56f54c08a823aedda55bc93b054 (just before my patch) - The number of callback functions (of decodeAudioData) is zero even when the leak occurs, where my patch must have noop. My best guess is that M64 has some issue (that ToT doesn't have) and my patch triggered that issue. Can someone (in testing team) bisect in which build the issue disappears? It must be somewhere between ToT and M64.
,
Feb 14 2018
> Can someone (in testing team) bisect in which build the issue disappears? It must be somewhere between ToT and M64. Sorry, ignore this part of comment. ToT does not have an issue from the beginning. And my patch in M64 is a merge patch. It's hard to find which patch resolves the issue. I've sent out a fix patch for review, without understanding the root cause. https://chromium-review.googlesource.com/c/chromium/src/+/918981 I don't see a behavioral change on ToT with/without this patch, but on M64 this patch resolves the memory leak.
,
Feb 15 2018
govind@ and everyone on this issue, As far as I tested, the issue doesn't reproduce on 65.0.3325.62 nor ToT. The issue only reproduces on M64. Now I'm not sure if I need to work on this issue only for M64 (assuming we'll respin M64). If we won't have M64 respin for this issue, then I don't see a reason that I need to work on a temporary/short-term hack to avoid the issue. If possible, I'd like to work on a long-term solution of this issue, which should be hard to merge into M64. Could someone cross-check that the issue doesn't occur on M65? Release managers, could you let me know if I should continue to work aiming a merge into M64?
,
Feb 15 2018
abdulsyed@ to comment on M64 merge. pbommana@@, could you pls check whether this repro or not on M65?
,
Feb 20 2018
Let's focus on a long-term fix in M65. The merge seems a bit risky for M64 at this stage, and we're only 2 weeks away from M65.
,
Feb 21 2018
M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 4:00 PM PT Monday (02/26/18) in order to make it to last M65 beta release next week. Thank you.
,
Feb 21 2018
I wasn't able to reproduce(On page refresh memory is freed i.e., with test page Memory footprint after cliking on the options jump to some where between 90Mb-107Mb and page refresh brings gets memory footprint back to 47Mb) the issue with M65 so far on Windows, mac and Linux with latest Chrome Chrome beta i.e., 65.0.3325.88.
,
Feb 21 2018
Removing "M-65" label based on comments #21 and #25. Thank you yukishiino@ and pbommana@.
,
Feb 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/37f11fd71e75bc3110215c11e03a00556be4845a commit 37f11fd71e75bc3110215c11e03a00556be4845a Author: Yuki Shiino <yukishiino@chromium.org> Date: Thu Feb 22 11:47:18 2018 v8binding: Implements v8::Persistent version of CallbackFunctionBase. CallbackFunctionBase and its subclasses retain the underlying v8::Function by using wrapper-tracing. However, wrapper-tracing is not always the best way to make the v8::Function alive. This patch implements V8PersistentCallbackFunction<T> that retains the v8::Function with using v8::Persistent so that it doesn't require wrapper-tracing. As a natural consequence, V8PersistentCallbackFunction<T> works very well with WrapPersistent unlike CallbackFunctionBase doesn't. Note that CallbackFunctionBase::Persistent was a persistent handle in terms of both of Blink GC and V8 GC, which is totally different from that V8PersistentCallbackFunction<T> is only a v8::Persistent and not a blink::Persistent. This difference should reduce the chance of memory leak caused by Oilpan reference cycles. I also have a plan to remove WrapPersistentCallbackFunction entirely and WrapPersistent for CallbackFunctionBase and its subclasses in order to prevent misuse of WrapPersistent. Bug: 779036 , 810701 Change-Id: I1c9d98a072d724d2d80141b87e718f06f8aba4ad Reviewed-on: https://chromium-review.googlesource.com/928783 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Hitoshi Yoshida <peria@chromium.org> Cr-Commit-Position: refs/heads/master@{#538404} [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/templates/callback_function.h.tmpl [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_any_callback_function_optional_any_arg.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_long_callback_function.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_string_sequence_callback_function_long_sequence_arg.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_dictionary_arg.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_enum_arg.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_interface_arg.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_test_interface_sequence_arg.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_typedef.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/bindings/tests/results/modules/v8_void_callback_function_modules.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/core/html/canvas/CanvasAsyncBlobCreator.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/core/html/canvas/CanvasAsyncBlobCreator.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/core/page/scrolling/ScrollStateCallback.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/core/page/scrolling/ScrollStateCallback.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/mediastream/UserMediaRequest.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/peerconnection/RTCSessionDescriptionRequestImpl.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/peerconnection/RTCSessionDescriptionRequestImpl.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/peerconnection/RTCStatsRequestImpl.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/peerconnection/RTCStatsRequestImpl.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/peerconnection/RTCVoidRequestImpl.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/peerconnection/RTCVoidRequestImpl.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/webaudio/AsyncAudioDecoder.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/webaudio/AsyncAudioDecoder.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.h [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/platform/bindings/CallbackFunctionBase.cpp [modify] https://crrev.com/37f11fd71e75bc3110215c11e03a00556be4845a/third_party/WebKit/Source/platform/bindings/CallbackFunctionBase.h
,
Feb 22 2018
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 23 2018
Removed ReleaseBlock-Stable as this issue doesn't happen in M65. Also marked as Fixed.
,
Feb 23 2018
Hi, Is there any chance this issue will be hotfixed in 64? This is a pretty major bug for HTML5 games. If not, how long can we expect until the release of 65 to stable?
,
Feb 26 2018
According to http://dev.chromium.org/developers/calendar , it seems that M65 stable will come on Mar 6th (note that this is "estimated stable dates").
,
Feb 26 2018
Just FYI, https://www.chromestatus.com/features/schedule .
,
Feb 28 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6ee8574fc0c94947246251d50a53ec77c1195c87 commit 6ee8574fc0c94947246251d50a53ec77c1195c87 Author: Yuki Shiino <yukishiino@chromium.org> Date: Wed Feb 28 08:36:34 2018 v8binding: Re-implements V8PersistentCallbackFunction. Following https://crrev.com/c/928783 , refactors V8PersistentCallbackFunction<T>. Major improvements: - V8PersistentCallbackFunction<T> is no longer a subclass of T. There will be no unintentional conversion between wrapper-tracing version and v8::Persistent version. - WrapPersistent(T*) = delete; where T is wrapper-tracing versions of callback functions. There will be no misuse of WrapPersistent for wrapper- tracing versions. Bug: 779036 , 810701 Change-Id: I7b83caa2b064b70e338892c873b1eb258d2a9c99 Reviewed-on: https://chromium-review.googlesource.com/931561 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Hitoshi Yoshida <peria@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#539758} [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/templates/callback_function.cpp.tmpl [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/templates/callback_function.h.tmpl [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_any_callback_function_optional_any_arg.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_any_callback_function_optional_any_arg.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_long_callback_function.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_long_callback_function.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_string_sequence_callback_function_long_sequence_arg.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_string_sequence_callback_function_long_sequence_arg.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_dictionary_arg.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_dictionary_arg.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_enum_arg.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_enum_arg.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_interface_arg.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_interface_arg.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_test_interface_sequence_arg.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_test_interface_sequence_arg.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_typedef.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/core/v8_void_callback_function_typedef.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/modules/v8_void_callback_function_modules.cc [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/bindings/tests/results/modules/v8_void_callback_function_modules.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/core/clipboard/DataTransferItem.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/core/clipboard/DataTransferItem.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/core/html/canvas/CanvasAsyncBlobCreator.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/core/mojo/MojoWatcher.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/core/page/scrolling/ScrollStateCallback.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/mediastream/UserMediaRequest.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/nfc/NFC.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/nfc/NFC.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/notifications/NotificationManager.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/notifications/NotificationManager.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/peerconnection/RTCSessionDescriptionRequestImpl.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/peerconnection/RTCStatsRequestImpl.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/peerconnection/RTCVoidRequestImpl.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/quota/DeprecatedStorageQuota.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/webdatabase/Database.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/modules/webdatabase/Database.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/platform/bindings/CallbackFunctionBase.cpp [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/platform/bindings/CallbackFunctionBase.h [modify] https://crrev.com/6ee8574fc0c94947246251d50a53ec77c1195c87/third_party/WebKit/Source/platform/heap/Persistent.h |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Feb 9 2018Components: Blink>MemoryAllocator
Labels: -Pri-2 ReleaseBlock-Stable M-64 M-65 Needs-Bisect Pri-1