Looks like a bug in https://github.com/crosswalk-project/chromium-crosswalk/blob/master/extensions/browser/api/networking_private/networking_private_linux.cc#L936

Duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=572539 - which attaches the patch, I've pushed a fix to https://github.com/NixOS/nixpkgs/commit/af4056f22ba52762c669551d90a3ec4d650bb233

To reproduce:

1. Go to chrome://flags
2. Set "Load Media Router Component Extension" to Enabled
3. Close chromium and reopen it
4. Observe it crash

Unable to reproduce the issue on Ubuntu 14.04,Windows 7 & Mac 10.12.5 using chrome reported version#58.0.3029.110,stable#59.0.3071.115 & Canary#61.0.3142.3 as per steps mentioned in comment#2.

No crash observed after enabling the above flag .Could you please check the same on latest chrome versions & let us know your observations on the same.

Thanks.

The same crash has been reported by at least 3 different Ubuntu users after the update to 59.0.3071.109 that enabled the media router extension by default. Details (including a complete backtrace) at https://launchpad.net/bugs/1702407.

Getting the same crash on Debian testing with Chromium verrsion 60.0.3112.78 (Developer Build).  Issue #702958  seems similar (it also mentions crashes with media router extension enabled).

We are unable to reproduce the issue in latest chrome stable build #62.0.3202.89. Marking it as WontFix since there are no feedback from user more than a month.Feel free to raise a new issue if still facing.

Thank You!

This issue very much reproduces in 62.0.3202.89 and still requires fixing.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881494
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882698

I'm still able to reproduce it on Fedora 27 using the browser shipped with the distribution - "Chromium 63.0.3239.108 Fedora Project". Since Fedora does not ship full debug symbols my findings are a bit circumstantial, but I'm pretty confident that they are correct.

By looking at System V AMD64 ABI calling conventions I was able to find with gdb that network_map that is passed around from GetAllWiFiAccessPoints down to AddOrUpdateAccessPoint is null.
The initial source of this value is GetNetworks:

  std::unique_ptr<NetworkMap> network_map(new NetworkMap);
  [...]
  dbus_thread_.task_runner()->PostTaskAndReply(
      FROM_HERE,
      base::Bind(&NetworkingPrivateLinux::GetAllWiFiAccessPoints,
                 base::Unretained(this), configured_only, visible_only, limit,
                 base::Unretained(network_map.get())),
      base::Bind(&NetworkingPrivateLinux::OnAccessPointsFound,
                 base::Unretained(this), base::Passed(&network_map),
                 success_callback, failure_callback));

The above (https://cs.chromium.org/chromium/src/extensions/browser/api/networking_private/networking_private_linux.cc?type=cs&q=GetAllWiFiAccessPoint&l=301) is the faulty line. At the first glance it looks correct, we get the network_map pointer and bind it to GetAllWiFiAccessPoints call and later we transfer the ownership of the pointer when binding to OnAccessPointsFound. We should be safe, becuse the object should exist till the second part is run, which is after GetAllWiFiAccessPoints call.

The problem is that C++ does not guarantee any specific argument evaluation order and what happens here is that on the crashing systems the arguments to PostTaskAndReply are evaluated in reverse order. The second Bind is evaluated first, which moves the ownership of network_map and causes network_map.get to return null which causes the crash later.

I also noticed that a similar pattern is used in different places (e.g. GetNetworksForScanRequest), so all of these places should also be fixed.

Thanks for investigating this, zhalas@!
stevenjb@ looks like this code was added by you, could you take a look at comment #11 and fix this crash?

The Linux code was added and is (was?) maintained by zentaro@, I merely reformatted it at one point in time.

Taking a quick glance at that code, I would also make sure that Unretained is valid there. On Chrome OS the DBus services may outlive the network handlers, so passing an unretained pointer to the dbus_thread_ may cause the callback to be invopked after the class itself was destroyed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1517db71cccaec48a05cdf30208e0cba7ab9b9a8

commit 1517db71cccaec48a05cdf30208e0cba7ab9b9a8
Author: Sergey Volk <servolk@google.com>
Date: Tue Jan 30 00:51:00 2018

Fix crashes due to evaluation order

Due to unspecified function argument evaluation order in C++ some
compilers might choose to evaluate base::Passed earlier than subsequent
smart pointer access, so we need to be extra careful and save raw
pointer values before using them. Otherwise they might no longer be
valid by the time we call ptr.get due to the pointer being already
modified by the base::Passed.

BUG=734325

Change-Id: Icb5a06c42c14018c98ab8ddaffcc1fd41f3111ab
Reviewed-on: https://chromium-review.googlesource.com/885091
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Zentaro Kavanagh <zentaro@chromium.org>
Commit-Queue: Sergey Volk <servolk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532704}
[modify] https://crrev.com/1517db71cccaec48a05cdf30208e0cba7ab9b9a8/extensions/browser/api/networking_private/networking_private_linux.cc

As per comment#5 and #8 issue is not reproducible from TE end. Hence it will not be possible to verify the issue from TE end, adding Needs-Feedback label.

@Reporter: Could you please verify the issue on latest canary 66.0.3335.0. You can download build from https://www.chromium.org/getting-involved/dev-channel.

Thanks!

Just tried it on "Version 66.0.3359.139 (Developer Build) built on Debian buster/sid, running on Debian buster/sid (64-bit)". Appears to be working now (no segfault thus far).

Thanks for the fix!

Version 66.0.3359.181 (chromium-66.0.3359.181-2.fc27.x86_64) has finally landed in Fedora 27 package repositories and since upgrading to that version I haven't observed any crashes. It looks like the fix is working. Thank you!