CC'ing owners.

I tried reproducing this with a Chromebook Pixel (Samus) with both M71 and M72 and didn't hit any DCHECKs. I'll keep trying to reproduce it artificially on Linux, but we'd appreciate it if you could us if you're still hitting this crash, or whether there's a page where you're more likely to hit it (e.g. https://intel.github.io/generic-sensor-demos/sensor-tester/build/bundled/).

Chrome OS builds don't have DCHECKs enabled. You would have to do your own Chromium build and load it onto your Chrome OS device.

We aren't seeing this in unit tests run with DCHECKs enabled because by default blocking IO is allowed from the main test thread. You can add a base::ScopedDisallowBlocking to PlatformSensorAndProviderLinuxTest::CreateSensor() and you start to see lots of failures.

Some of these failures are due to the test only having one thread rather than the usual two. If that is fixed then you will see this issue reproduce.

In general we should move this code away from being passed an explicit "file task runner" and instead use TaskTraits to post potentially blocking operations to a worker pool thread.

Ah, thanks for the heads-up about DCHECKs in builds, I thought the dev channel had them enabled. I've been catching up with the (not so) recent status quo with TaskTraits/TaskScheduler and friends and the transition from the old APIs and should be able to produce something useful soon.

For the record and in case this helps people in the future, it's very easy to reproduce this on a regular Linux machine without any sensors by loading the iio_dummy Linux kernel module (I had to build it manually on Fedora) and "creating" a dummy sensor via `mkdir /sys/kernel/config/iio/devices/dummy/foo`. Trying to instantiate any sensor on a debug build then fails that very same DCHECK. Looking at the code history, I'm guessing that problem's always been there but not a lot of people with sensors on their machines launch debug builds on Linux/CrOS and open a page that uses any sensors.

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

commit dd9b04ee8e13eadac293fb520201af1bca938145
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Fri Nov 09 21:44:25 2018

sensors: Remove bogus DCHECK from SensorReader::Create()

There is no reason to require SensorReader instances to be created in a
thread/task that allows blocking: SensorReader already uses a ThreadChecker
and all methods verify they are being called from the right thread (i.e. one
that can block).

The call to base::AssertBlockingAllowedDeprecated() has been there since the
code was added in commit 061d113db ("[sensors](CrOS/Linux) Implement Sensor
device manager for sensors"), but the existing unit tests behaved
differently from the production code paths and not many people seem to have
used a Linux or ChromeOS build with DCHECKs enabled on a machine with
sensors.

PlatformSensorAndProviderLinuxTest has been adjusted and now almost all code
runs within a base::ScopedDisallowBlocking scope to better mimic production
conditions. Care has been taken to avoid changing too much code: porting
classes and tests to base::PostTask() and reducing the amount of task
runners passed around will be done separately.

Bug:  896382 
Change-Id: I374acba4ec982cf5ae49eb44e410607e57ac85c0
Reviewed-on: https://chromium-review.googlesource.com/c/1329921
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#606978}
[modify] https://crrev.com/dd9b04ee8e13eadac293fb520201af1bca938145/services/device/generic_sensor/platform_sensor_and_provider_unittest_linux.cc
[modify] https://crrev.com/dd9b04ee8e13eadac293fb520201af1bca938145/services/device/generic_sensor/platform_sensor_reader_linux.cc