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

Issue 663575 link

Starred by 5 users

Issue metadata

Status: Duplicate
Owner: ----
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Signing into Chrome causes Segmentation Fault/Core Dump with authenticated proxy requirement

Reported by bernard_...@debortoli.com.au, Nov 9 2016

Issue description

Chrome Version (from the about:version page): 53.0.2785.143
Is this the most recent version: yes (for Ubuntu 16.04)
OS + version: Ubuntu 16.04
CPU architecture (32-bit / 64-bit): 64 bit
Window manager: KDE
URLs (if relevant):
Behavior in Linux Firefox: Segmentation Fault when I try to login
Behavior in Windows Chrome (if you have access to it):

What steps will reproduce the problem?
(1) Configure proxy settings to use an authenticated proxy
(2) Click the user icon in the title bar, and choose [Sign into Chromium]
(3) A dialog overlay and spinning logo appear briefly -> segfault

What is the expected result?
A dialog overlay appears where I can enter my username and password


What happens instead?
The browser crashes with the message:
> Segmentation fault (core dumped)

Please provide any additional information below. Attach a screenshot
and backtrace if possible.

strace output attached

Videos of the process (failing with auth proxy, working with no auth proxy):
mp4: https://drive.google.com/file/d/0B3HLJgx8Sj1WeDdQb1RqZWVualk/view?usp=sharing
ogv: https://drive.google.com/file/d/0B3HLJgx8Sj1WT2hZZHRreVY2aVk/view?usp=sharing


 
chromium-browser.strace
3.0 MB Download
Replicated in KDE and Unity so far, it doesn't seem to be related to the Desktop Environment -
Labels: TE-NeedsTriageHelp
Does Google Chrome have the same problem? If yes, can you get a crash report id? https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug

Who build the Chromium browser you are running?
> Does Google Chrome have the same problem? 

Yes - just confirmed on chrome from the official google repo on the following versions:
* stable:   54.0.2840.90-1 
* beta:     55.0.2883.35-1
* unstable: 56.0.2906.0-1

> If yes, can you get a crash report id? 
Crash ID: crash/3ba82e6700000000


> Who build the Chromium browser you are running?
Chad MILLER <chad.miller@canonical.com> [1]

[1]: from the changelog:
chromium-browser (53.0.2785.143-0ubuntu0.16.04.1.1254) xenial-security; urgency=medium

  * Upstream release 53.0.2785.143:
    - CVE-2016-5177: Use after free in V8.
    - CVE-2016-5178: Various fixes from internal audits, fuzzing and other
      initiatives.
  * Upstream release 53.0.2785.113:
    - CVE-2016-5170: Use after free in Blink.
    - CVE-2016-5171: Use after free in Blink.
    - CVE-2016-5172: Arbitrary Memory Read in v8.
    - CVE-2016-5173: Extension resource access.
    - CVE-2016-5174: Popup not correctly suppressed.
    - CVE-2016-5175: Various fixes from internal audits, fuzzing and other
      initiatives.
  * debian/rules: Use gold ld to link.
  * debian/rules: Kill delete-null-pointer-checks. In the javascript engine,
    we can not assume a memory access to address zero always results in a
    trap.
  * debian/patches/gsettings-display-scaling,
    debian/patches/display-scaling-default-value, reenable DPI scaling taken
    from dconf.
  * debian/rules: explicitly set target arch for arm64.
  * debian/control, debian/rules: re-add -dbg transitional packages.
  * Upstream release 53.0.2785.89:
    - CVE-2016-5147: Universal XSS in Blink.
    - CVE-2016-5148: Universal XSS in Blink.
    - CVE-2016-5149: Script injection in extensions.
    - CVE-2016-5150: Use after free in Blink.
    - CVE-2016-5151: Use after free in PDFium.
    - CVE-2016-5152: Heap overflow in PDFium.
    - CVE-2016-5153: Use after destruction in Blink.
    - CVE-2016-5154: Heap overflow in PDFium.
    - CVE-2016-5155: Address bar spoofing.
    - CVE-2016-5156: Use after free in event bindings.
    - CVE-2016-5157: Heap overflow in PDFium.
    - CVE-2016-5158: Heap overflow in PDFium.
    - CVE-2016-5159: Heap overflow in PDFium.
    - CVE-2016-5161: Type confusion in Blink.
    - CVE-2016-5162: Extensions web accessible resources bypass.
    - CVE-2016-5163: Address bar spoofing.
    - CVE-2016-5164: Universal XSS using DevTools.
    - CVE-2016-5165: Script injection in DevTools.
    - CVE-2016-5166: SMB Relay Attack via Save Page As.
    - CVE-2016-5160: Extensions web accessible resources bypass.
    - CVE-2016-5167: Various fixes from internal audits, fuzzing and other
      initiatives.
  * debian/patches/cups-include-deprecated-ppd, debian/rules: include cups
    functions.
  * debian/rules, debian/control: Force using gcc-5 compiler.
  * Use system libraries for expat, speex, zlib, opus, png, jpeg.
  * Also build for arm64 architecture.
  * Don't compile in cups support by default on all architectures.
  * debian/control: remvove build-dep on clang.
  * debian/patches/linux45-madvfree: If MADV_FREE is not defined, do not allow
    it in sandbox filter. Also, undefine it so we don't use MADV_FREE and
    thereby depend on it at runtime.
  * debian/rules: Use gold ld to link.
  * debian/rules: Kill delete-null-pointer-checks. In the javascript engine,
    we can not assume a memory access to address zero always results in a
    trap.
  * debian/patches/series, debian/rules: Re-enable widevine component.

 -- Chad MILLER <chad.miller@canonical.com>  Fri, 16 Sep 2016 12:56:44 -0400



Cc: fsam...@chromium.org wjmaclean@chromium.org imch...@chromium.org msw@chromium.org
Components: Internals>Network>Proxy
Labels: Stability-Crash
Status: Untriaged (was: Unconfirmed)
CCing some people who might know about this. The stacktrace from the Google Chrome crash is below:

#0  delegate (this=0x0) at ../../components/web_modal/web_contents_modal_dialog_manager.h:30
#1  CreateWebModalDialogViews (web_contents=0x37cd4a4daa00, dialog=<optimized out>) at ../../components/constrained_window/constrained_window_views.cc:194
#2  constrained_window::ShowWebModalDialogViews (dialog=0x37cd4a6f7f90, initiator_web_contents=<optimized out>)
    at ../../components/constrained_window/constrained_window_views.cc:162
#3  0x00005569a0699334 in LoginHandlerViews::BuildViewImpl (this=0x37cd4a6f7c00, authority=..., explanation=..., login_model_data=<optimized out>)
    at ../../chrome/browser/ui/views/login_handler_views.cc:121
#4  0x00005569a04c0395 in BuildViewWithoutPasswordManager (this=0x37cd4a6f7c00, authority=..., explanation=...) at ../../chrome/browser/ui/login/login_handler.cc:151
#5  LoginHandler::ShowLoginPrompt (request_url=..., auth_info=0x37cd4bf4fac0, handler=0x37cd4a6f7c00) at ../../chrome/browser/ui/login/login_handler.cc:550
#6  0x000055699e520bd0 in content::InterstitialPageImpl::OnDomOperationResponse (this=0x37cd4bf5a900, json_string=...)
    at ../../content/browser/frame_host/interstitial_page_impl.cc:861
#7  0x000055699e520ca0 in DispatchToMethodImpl<content::InterstitialPageImpl*, void (content::InterstitialPageImpl::*)(std::basic_string<char> const&), std::tuple<std::basic_string<char> > const&, 0> (method=<optimized out>, obj=<optimized out>, args=...) at ../../base/tuple.h:144
#8  DispatchToMethod<content::InterstitialPageImpl*, void (content::InterstitialPageImpl::*)(std::basic_string<char> const&), std::tuple<std::basic_string<char> > const&> (
    obj=<optimized out>, method=<optimized out>, args=...) at ../../base/tuple.h:151
#9  DispatchToMethod<content::InterstitialPageImpl, void (content::InterstitialPageImpl::*)(std::basic_string<char> const&), void, std::tuple<std::basic_string<char> > > (
    obj=<optimized out>, method=<optimized out>, tuple=...) at ../../ipc/ipc_message_templates.h:26
#10 IPC::MessageT<FrameHostMsg_DomOperationResponse_Meta, std::tuple<std::string>, void>::Dispatch<content::InterstitialPageImpl, content::InterstitialPageImpl, void, void (content::InterstitialPageImpl::*)(std::string const&)> (msg=0x37cd4bc659b0, obj=<optimized out>, sender=<optimized out>, parameter=<optimized out>, func=<optimized out>)
    at ../../ipc/ipc_message_templates.h:121
#11 0x000055699e5201f1 in content::InterstitialPageImpl::OnMessageReceived (this=0x37cd4bf5a900, render_frame_host=<optimized out>, message=...)
    at ../../content/browser/frame_host/interstitial_page_impl.cc:361

I have run into a similar issue before (crbug.com/649191) where the solution is to invoke CreateWebModalDialogViews with the top-level WebContents of the given WebContents because only the top-level WC is guaranteed to have a WebContentsModalDialogManager. My issue was using a different code path though. It looks like the stack trace in c#5 is already using the top-level WebContents, but we are still getting a nullptr WebContentsModalDialogManager. Why is that?
> It looks like the stack trace in c#5 is already using the top-level 
> WebContents, but we are still getting a nullptr 
> WebContentsModalDialogManager. Why is that?

I've observed some symptoms that may help narrow it down:

Scenario 1: 
* browse to a http/s page, 
* authenticate against the proxy (*before* attempting to sign in to chrome)
* sign in via the title bar button 
-> Segfault

Scenario 2:
* browse to chrome://chrome-signin/?access_point=0&reason=0
* authenticate against the proxy
* sign in via the in page form
-> page hangs with a spinning dialog, or immediately returns failure via overlay in the top right corner

Scenario 3:
* browse to chrome://chrome-signin/?access_point=0&reason=0
* authenticate against the proxy
* browse to a http/s page, 
* authenticate against the proxy (again!)
* sign in via the in page form
-> success (usually...)

Scenario 4:
* browse to chrome://chrome-signin/?access_point=0&reason=0
* authenticate against the proxy
* browse to a http/s page, 
* authenticate against the proxy (again!)
* sign in via the title bar button
-> overlay dialog appears, and login succeeds

The key point is that my successful proxy authentication token for the chrome:// url is ignored when I then try to browse a http/s url - therefore I have to authenticate against the proxy again.

This problem also occurs on the latest version of Chrome on Microsoft Windows.  I have reproduced it in older versions of Chrome too, it does not appear to be a new issue.

Comment 9 by mmenke@chromium.org, Jul 27 2017

Components: -Internals>Network>Proxy UI>SignIn Internals>Network>Auth
Mergedinto: 629529
Status: Duplicate (was: Untriaged)
Merged into a bug I don't have permission to see :(

Regardless, there's some good news in 61.0.3163.79 - no more segfault!


chromium.png
44.3 KB View Download

Sign in to add a comment