I think having Feature Policy disabled is causing tabs to crash.
Reported by
greyp...@gmail.com,
Feb 7 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Steps to reproduce the problem: 1. Click on a link that searches for something on Google 2. See crash. 3. What is the expected behavior? Search results. What went wrong? Tab crashes. See "any other comments" below. Did this work before? Yes 63 Chrome version: 64.0.3282.140 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Since upgrading to current (64, mainstream), I've been getting a weird tab crash just going to Google. It's not all the time, which makes it frustrating to track down, and I'm not smart enough to figure how to. It happens in multiple profiles, as well as incognito tabs. As near as I can tell, it has something to do with the 'Feature Policy' flag, which I have disabled. Or, at least, that's where it's crapping out(?): Failed calling InternetOpenUrl, GLE=12029 FAULTING_IP: chrome_child!std::map<blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault,std::less<blink::FeaturePolicyFeature>,std::allocator<std::pair<const blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault> > >::at+4 [c:\b\c\win_toolchain\vs_files\a9e1098bba66d2acccc377d5ee81265910f29272\vc\tools\msvc\14.11.25503\include\map @ 364] 000007fe`c6b93d26 4c8b01 mov r8,qword ptr [rcx] EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 000007fec6b93d26 (chrome_child!std::map<blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault,std::less<blink::FeaturePolicyFeature>,std::allocator<std::pair<const blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault> > >::at+0x0000000000000004) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: 0000000000000080 Attempt to read from address 0000000000000080 PROCESS_NAME: chrome.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: 0000000000000080 READ_ADDRESS: 0000000000000080 FOLLOWUP_IP: chrome_child!std::map<blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault,std::less<blink::FeaturePolicyFeature>,std::allocator<std::pair<const blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault> > >::at+4 [c:\b\c\win_toolchain\vs_files\a9e1098bba66d2acccc377d5ee81265910f29272\vc\tools\msvc\14.11.25503\include\map @ 364] 000007fe`c6b93d26 4c8b01 mov r8,qword ptr [rcx] MOD_LIST: <ANALYSIS/> NTGLOBALFLAG: 0 FAULTING_THREAD: 0000000000003230 BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_READ PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE LAST_CONTROL_TRANSFER: from 000007fec6b93c88 to 000007fec6b93d26 STACK_TEXT: 00000000`003ad8e0 000007fe`c6b93c88 : 00000000`003ad9a0 000007fe`c96d1f32 0000078b`ccc22718 000007fe`c9df4778 : chrome_child!std::map<blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault,std::less<blink::FeaturePolicyFeature>,std::allocator<std::pair<const blink::FeaturePolicyFeature,blink::FeaturePolicy::FeatureDefault> > >::at+0x4 [c:\b\c\win_toolchain\vs_files\a9e1098bba66d2acccc377d5ee81265910f29272\vc\tools\msvc\14.11.25503\include\map @ 364] 00000000`003ad910 000007fe`c9c5c8f0 : 00000000`00000000 000007fe`c9c5decb 00000000`00000014 000007fe`c9c600ae : chrome_child!blink::FeaturePolicy::IsFeatureEnabledForOrigin+0x2e [C:\b\c\b\win64_clang\src\third_party\WebKit\common\feature_policy\feature_policy.cc @ 126] 00000000`003ad970 000007fe`c9c5c784 : 00000000`047d47f8 00000000`02d42dd0 00000000`003ae2c0 00000169`d2382321 : chrome_child!blink::Geolocation::StartRequest+0x92 [C:\b\c\b\win64_clang\src\third_party\WebKit\Source\modules\geolocation\Geolocation.cpp @ 246] 00000000`003ad9d0 000007fe`c9daa8ba : 00000000`00000000 00000000`00000000 00000000`003adeb8 00000000`047d47a8 : chrome_child!blink::Geolocation::getCurrentPosition+0xc6 [C:\b\c\b\win64_clang\src\third_party\WebKit\Source\modules\geolocation\Geolocation.cpp @ 208] 00000000`003ada50 000007fe`c6aca972 : 000007fe`c9f73b60 00000000`003ad698 00000000`02d42dd0 00000000`00000000 : chrome_child!blink::V8Geolocation::getCurrentPositionMethodCallback+0x48a [C:\b\c\b\win64_clang\src\out\Release_x64\gen\blink\bindings\modules\v8\V8Geolocation.cpp @ 204] 00000000`003adb20 000007fe`c749dc3a : 00000000`00000000 000001f0`e18c0101 00000006`00000003 00000000`1f65f901 : chrome_child!v8::internal::FunctionCallbackArguments::Call+0x1d2 [C:\b\c\b\win64_clang\src\v8\src\api-arguments.cc @ 25] 00000000`003adc40 000007fe`c749d500 : 00000000`047d47e0 00000000`047d47a0 00000000`047d6740 00000000`003adeb8 : chrome_child!v8::internal::`anonymous namespace'::HandleApiCallHelper<0>+0x38a [C:\b\c\b\win64_clang\src\v8\src\builtins\builtins-api.cc @ 112] 00000000`003add30 000007fe`c6aca58e : 000055af`2b367673 000007fe`c6abcc00 00000000`003ade88 00000000`000000f8 : chrome_child!v8::internal::Builtin_Impl_HandleApiCall+0x110 [C:\b\c\b\win64_clang\src\v8\src\builtins\builtins-api.cc @ 142] 00000000`003addf0 000003cc`c7884321 : 000003cc`c7908117 00000000`00000057 00000000`003adec8 00000000`02d81690 : chrome_child!v8::internal::Builtin_HandleApiCall+0x3e [C:\b\c\b\win64_clang\src\v8\src\builtins\builtins-api.cc @ 130] Snipped the rest, because it's probably not relevant. I have Chromium Portable dev 65 without this issue as far as I know. Is it possible there's a path that expects some structure to exist that doesn't when the Feature Policy is disabled, and hence this? Or is this the symptom of something else?
,
Feb 8 2018
Unable to reproduce the issue on chrome reported version 64.0.3282.140 using windows-7 with steps mentioned below: 1) Launched chrome reported version and disabled 'Feature Policy' flag 2) Clicked on a link that searches for something on Google 3) Shown the search results @Reporter: Please find the attached screencast for your reference, try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists. Thanks!
,
Feb 8 2018
,
Feb 8 2018
Greetings, and thank you for looking! I don't suppose there's a way to securely submit the various dmp files the crashes generated, which would protect whatever personal and private information is in the memory, is there? Would that be useful in confirming the existence of the bug, at least? To try to clarify information, this only occurs going directly to Google search pages. For example, one search was "dog fence": https://www.google.com/search?q=dog+fence&oq=dog+fence&aqs=chrome..69i57j69i59.2495j0j9&sourceid=chrome&ie=UTF-8 Directly pasting that into the browser, resulted in a crashed tab. After that, opening an incognito window, and pasting that exact same URL, resulted in the same tab crash! After which, *any* search seemed to result in the same. I would see the Google search results for about a second, and then the tab error (see picture). While I had extensions running (in my primary instance) and in my secondary profile, I want to state again: the exact same crash you see in the picture happened in an incognito window, with no extensions running (given permission to run in incognito). I've never seen this happen in my primary profile. (I'll also note that I tend to play with flags, see second picture) Which is to say that this is likely some very edge case that most users wouldn't encounter. After heavy usage in a second profile, this then affects the _primary_ profile and _incognito_ windows. Let me explain that again. In the secondary profile, I am commonly opening 10+ tabs for various searches, closing, then moving on to a new search. After maybe 20-100ish (varies) of these, I was able to trigger this, such that the tab in the secondary profile would crash, and then copying and pasting ('dog fence' query above - though the query doesn't seem to matter, that's just the last one I recall; others were just as mundane) the search url into the *Primary* profile would have the same crash, _as well as_ if I opened an incognito window and directly pasted the url there. If, however, I restart the browser, and paste, it works! Until some hours (usually) later. Since there's no step by step to reproduce beyond time(?) I'm not sure how to give something more useful, or, given the unlikeliness it'll affect many people, if it's something anyone would/should care about. (Also, I apologize for my ignorance about the bug reporting process, as it's my first.) I realize this sounds like a classic memory issue (32gb - plenty free), but it doesn't affect any of the other instances of Chrome (Portable, Chromium) running, or Opera, or Slimjet. I also never saw anything like this, with the same general app set running, and the _exact same workflow_ (profiles, extensions), prior to 64.0.3282.140. Given the 'nothing else has changed' (TM) nature, I'm led to believe it's something that must have recently changed. Given the stack trace (which, I'll note, I only knew how to do via Googling, and don't actually understand! :) ) is what led me to think it has something to do with the Feature Policy not being set to 'Default'. Thank you again for looking into it and please let me know if there is any way of actually narrowing down what's going on with something like this that only happens "eventually" but not consistently!
,
Feb 8 2018
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 9 2018
Tested the issue on reported version 64.0.3282.140 using Mac 10.13.3, Ubuntu 14.04 and Windows 10 and able to reproduce this issue. But issue is fixed in latest dev 65.0.3325.51 and latest canary 66.0.3344.0. Hence providing reverse bisect info. Able to reproduce this issue by disabling feature policy flag and navigating to link given in comment#4. Last Bad Build: 65.0.3325.39 First Good Build: 65.0.3325.45 Unable to perform per-revision bisect as this issue is broken in branch builds.Hence assigning from manual changelog CR: https://chromium.googlesource.com/chromium/src/+log/65.0.3325.39..65.0.3325.45?pretty=fuller&n=10000 Suspecting https://chromium-review.googlesource.com/893598 from changelog. @ iclelland: Please confirm whether this is safe to merge to M-64. Adding RB-Stable for M-64, please change if not the case Thanks!
,
Feb 9 2018
Yes that patch will definitely fix the issue; it is already merged to M64, as of 64.0.3282.152 (which unfortunately *just* missed the last stable push) The FeaturePolicyForPermissions feature depends on the FeaturePolicy flag, but doesn't check for it properly; this patch marks the dependency so that if FeaturePolicy is disabled, then the related features are as well. Besides re-enabling feature policy (which is shipped as stable), the other workaround for desktop users is to run Chrome with the command line --disable-blink-features=FeaturePolicyForPermissions (See the original bug, 806362 for context as well)
,
Feb 9 2018
I don't think there's any additional action to take here; the patch in question has been applied to 64, 65 and 66 branches. Marking as duplicate of https://crbug.com/806362 and cc'ing the M64 desktop owner.
,
Feb 9 2018
Not sure if working as intended, but the original bug (https://crbug.com/806362) doesn't appear viewable(?): You do not have permission to view the requested page. Reason: User is not allowed to view this issue Else I probably would have been able to search on it and not have bugged you good folk. :^)
,
Feb 9 2018
I appreciate you taking the time to dig into it; I don't know what the policy on visibility is, but I agree that would have made it a lot quicker to debug. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by susanjun...@techmahindra.com
, Feb 7 2018