Opening links inside of an iframe when an extension is running crashes the current tab
Reported by
bigh...@gmail.com,
Nov 13 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 Steps to reproduce the problem: 0. Install Imagus extension: https://chrome.google.com/webstore/detail/imagus/immpkjjlgappgfkkfieppnmlhakdmaab?hl=en 1. Open a page that contains content and links in an iframe (for example, https://www.w3schools.com/html/html_iframe.asp has links inside of an iframe, or any Youtube embedded video will do) 2. Right click on a link and select "Open link in a new tab" 3. Tab has now crashed and you should see "Aw, Snap!" page This only happens when Imagus extension is enabled. This only happens under Linux. Interestingly, it does not crash if I Ctrl+click on a link. It only happens when I right click and open the page in a new tab that way. And once you ctrl+click on a link, subsequent right clicking and "open in new tab" won't crash the tab. What is the expected behavior? Extensions shouldn't be able to crash a page. What went wrong? Tab crashes. Crashed report ID: No. I run Chromium, not Chrome. How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? N/A Chrome version: 62.0.3202.89 Channel: stable OS Version: Flash Version:
,
Nov 14 2017
Unable to reproduce the issue on reported chromium version 62.0.3202.89 using Ubuntu 14.04. Please find the attached screen-cast and let us know if we have missed any steps in the process of reproducing the issue from TE-end
,
Nov 14 2017
It was confirmed by users on Reddit: https://www.reddit.com/r/imagus/comments/7ckhyx/imagus_crashes_chromium_pages_that_have_iframes/dprgo2t/ I do not know why your version does not crash but it does crash my Chromium. See the attached video.
,
Nov 14 2017
And here is a video when I disable Imagus. No crashed tab. The extension is definitely causing crashes under Linux with 62.0.3202.94 (Developer Build) (64-bit)
,
Nov 14 2017
Thank you for providing more feedback. Adding requester "divya.padigela@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
,
Nov 15 2017
I followed exactly the steps in your video and I'm still unable to reproduce with Google Chrome 62 (stable) or 64 (dev). Presumably you're using the Chromium from your distro's packages? Which distro are you using? Could you try testing with Google Chrome instead?
,
Nov 15 2017
Thomas, I use Arch. The package in question is: https://www.archlinux.org/packages/extra/x86_64/chromium/ I do not know if other people who experience this tab crash also use this build. I have tried it With Chrome 62.0.3202.94 (Official Build) (64-bit) and it does not exhibit this behavior. With Imagus enabled, it does not crash. So the fault is definitely with Chromium.
,
Nov 15 2017
Also, I have a bunch of chrome://flags enabled. Command line from chrome://version looks like this: /usr/lib/chromium/chromium --flag-switches-begin --enable-fast-unload --enable-gpu-rasterization --disable-offer-store-unmasked-wallet-cards --enable-picture-in-picture --enable-quic --enable-zero-copy --ignore-gpu-blacklist --num-raster-threads=4 --save-page-as-mhtml --enable-features=ExpensiveBackgroundTimerThrottling,HttpFormWarning,MemoryCoordinator,NewAudioRenderingMixingStrategy,OmniboxTailSuggestions,OverlayScrollbar,PauseBackgroundTabs --disable-features=MaterialDesignBookmarks,MaterialDesignExtensions,MaterialDesignIncognitoNTP,WebUSB --flag-switches-end I do not know if any of them could be causing this. Maybe someone more knowledgable could take a quick look.
,
Nov 15 2017
Hm.. I tried with those flags and I still can't repro. I'm afraid there's not much I can do to help. But there is one last hope you can try: bisection. We have a utility that makes bisecting very easy. You don't need to do any builds or even have a chromium checkout. $ curl -s --basic -n "https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT" | base64 -d > bisect-builds.py $ python bisect-builds.py -a linux64 -g 400000
,
Nov 15 2017
Thomas, Thanks for the advice. Also, could you download the Chromium build from one of the mirrors and see if it exhibits same behavior for you? https://www.archlinux.org/packages/extra/x86_64/chromium/download/ I've now tested this build on another machine (my laptop) and it too crashes tabs with Imagus enabled.
,
Nov 15 2017
Unable to reproduce the issue on ubuntu 14.04 using 62.0.3202.89 (Official Build) Built on Ubuntu. Observed that tab did not crash and opened in another tab without any issues. Hence, removing the Needs-Bisect label as it is not reproducible from TE-end. Please feel free to add the same if required. Thanks...!!
,
Nov 18 2017
I'm able to reproduce the bug on the chromium I downloaded from https://www.archlinux.org/packages/extra/x86_64/chromium/download/ I'm also unable to repro using the chromium browser in Debian Testing, nor my locally built chromium. I'd file a bug with arch as this appears somehow arch-specific. If it turns out the bug can be fixed upstream, plmk and I'd be happy to assist with upstreaming.
,
Nov 18 2017
The crash occurs in blink::Node::EnclosingLinkEventParentOrSelf() due to a GCC 6 (and later) optimization. In the for loop, the initialization part is `const Node* node = this` and the condition is `node` (i.e. node != NULL). As per [1], GCC assumes the `this` pointer (and, therefore, `node`) is not NULL during the first iteration and optimizes away the check. Chrome avoids this issue by using clang, and Debian works around it by adding '-fno-delete-null-pointer-checks' to their compiler flags. I'm also aware that GCC is considered unsupported for building Chromium and, as such, I will switch Arch's Chromium to build with clang. This should fix this issue and possibly avoid similar ones in the future. Btw, I'd welcome being cc'ed in bugs that occur on Arch but are not reproducible on other platforms and/or with Chrome. Considering the number of people involved with bug handling, I suppose that might not be possible though. (The "file a bug with arch as this appears somehow arch-specific" approach is also good.) [1] https://gcc.gnu.org/gcc-6/changes.html For the record, this is the assembly instruction where Arch's Chromium crashed: Dump of assembler code for function _ZNK5blink4Node30EnclosingLinkEventParentOrSelfEv: 0x000055555bb926f0 <+0>: sub $0x8,%rsp 0x000055555bb926f4 <+4>: mov %rdi,%rax 0x000055555bb926f7 <+7>: nopw 0x0(%rax,%rax,1) => 0x000055555bb92700 <+16>: mov 0x10(%rax),%edx 0x000055555bb92703 <+19>: test $0x1,%dh 0x000055555bb92706 <+22>: je 0x55555bb92728 <blink::Node::EnclosingLinkEventParentOrSelf() const+56> 0x000055555bb92708 <+24>: and $0x10,%edx 0x000055555bb9270b <+27>: je 0x55555bb92737 <blink::Node::EnclosingLinkEventParentOrSelf() const+71> 0x000055555bb9270d <+29>: lea 0x3076c54(%rip),%rdx # 0x55555ec09368 <blink::HTMLNames::imgTag> 0x000055555bb92714 <+36>: mov 0x50(%rax),%rcx 0x000055555bb92718 <+40>: mov (%rdx),%rdx 0x000055555bb9271b <+43>: mov (%rdx),%rdx 0x000055555bb9271e <+46>: mov 0x10(%rdx),%rsi 0x000055555bb92722 <+50>: cmp %rsi,0x10(%rcx) 0x000055555bb92726 <+54>: jne 0x55555bb92737 <blink::Node::EnclosingLinkEventParentOrSelf() const+71> 0x000055555bb92728 <+56>: xor %esi,%esi 0x000055555bb9272a <+58>: mov %rax,%rdi 0x000055555bb9272d <+61>: callq 0x55555bb74eb0 <blink::FlatTreeTraversal::TraverseParent(blink::Node const&, blink::LayoutTreeBuilderTraversal::ParentDetails*)> 0x000055555bb92732 <+66>: test %rax,%rax 0x000055555bb92735 <+69>: jne 0x55555bb92700 <blink::Node::EnclosingLinkEventParentOrSelf() const+16> 0x000055555bb92737 <+71>: add $0x8,%rsp 0x000055555bb9273b <+75>: retq End of assembler dump.
,
Nov 20 2017
Thanks for the followup. I'll add -fno-delete-null-pointer-checks to the gcc config in case anyone is still doing gcc builds. If I see any more bugs that are Arch-specific, I'll be sure to CC you.
,
Nov 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/64aeb9ca82032d378388365aebbbd71c3e1e8e5b commit 64aeb9ca82032d378388365aebbbd71c3e1e8e5b Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Nov 20 23:50:32 2017 Don't optimize away null pointer checks on gcc GCC assumes 'this' is never nullptr and optimizes away code like "if (this == nullptr) ...": [1]. However, some Chromium code relies on these types of null pointer checks [2], so disable this optimization. [1] https://gcc.gnu.org/gcc-6/porting_to.html#this-cannot-be-null [2] https://crbug.com/784492#c13 BUG= 784492 R=brettw@chromium.org Change-Id: I45343193acc6ae52da37687a126f02665b48a5d5 Reviewed-on: https://chromium-review.googlesource.com/779979 Reviewed-by: Brett Wilson <brettw@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#517998} [modify] https://crrev.com/64aeb9ca82032d378388365aebbbd71c3e1e8e5b/build/config/compiler/BUILD.gn
,
Oct 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cd574787c2c1be491cfdd221a0d3a757c4ec63b7 commit cd574787c2c1be491cfdd221a0d3a757c4ec63b7 Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Oct 22 20:15:30 2018 Enable this!=nullptr checks in release builds BUG= 784492 R=thakis Change-Id: I4a2d637f9fab0fb2bc4c05dc0637a73233b21ae7 Reviewed-on: https://chromium-review.googlesource.com/c/1294449 Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#601704} [modify] https://crrev.com/cd574787c2c1be491cfdd221a0d3a757c4ec63b7/build/config/compiler/BUILD.gn [modify] https://crrev.com/cd574787c2c1be491cfdd221a0d3a757c4ec63b7/third_party/blink/renderer/core/dom/node.cc [modify] https://crrev.com/cd574787c2c1be491cfdd221a0d3a757c4ec63b7/third_party/blink/renderer/core/frame/web_local_frame_impl.cc |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by manoranj...@chromium.org
, Nov 13 2017Components: Blink>HTML>IFrame
Labels: Needs-Bisect Needs-Triage-M62