New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 784492 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Opening links inside of an iframe when an extension is running crashes the current tab

Reported by bigh...@gmail.com, Nov 13 2017

Issue description

UserAgent: 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:
 
Cc: thomasanderson@chromium.org
Components: Blink>HTML>IFrame
Labels: Needs-Bisect Needs-Triage-M62
Labels: Triaged-ET Needs-Feedback
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

784492.ogv
10.4 MB View Download

Comment 3 by bigh...@gmail.com, 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.
test-si.webm
2.8 MB View Download

Comment 4 by bigh...@gmail.com, 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)

test-swi.webm
2.6 MB View Download
Project Member

Comment 5 by sheriffbot@chromium.org, Nov 14 2017

Cc: divya.pa...@techmahindra.com
Labels: -Needs-Feedback
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
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?

Comment 7 by bigh...@gmail.com, 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.
Screenshot from 2017-11-14 19-31-16.jpg
51.2 KB View Download

Comment 8 by bigh...@gmail.com, 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.
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

Comment 10 by bigh...@gmail.com, 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.
Labels: -Needs-Bisect
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...!!

Status: WontFix (was: Unconfirmed)
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.
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.
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.
Project Member

Comment 15 by bugdroid1@chromium.org, 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

Project Member

Comment 16 by bugdroid1@chromium.org, Oct 22

Sign in to add a comment