I see this error popping up occasionally on release builders over the last few weeks:

http://stainless/search?view=list&first_date=2018-12-04&last_date=2018-12-17&test=%5Etast%5C.security%5C.ASLR%24&status=FAIL&status=ERROR&reason=Mapping+for&exclude_cts=false&exclude_not_run=false&exclude_non_release=true&exclude_au=true&exclude_acts=true&exclude_retried=true&exclude_non_production=false

I'll mark the test informational again.

It's worthwhile checking if this happens in the security_ASLR Autotest test too.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/c90334abfd86b9db3095a78e0e295c4feeb25490

commit c90334abfd86b9db3095a78e0e295c4feeb25490
Author: Dan Erat <derat@chromium.org>
Date: Mon Dec 17 22:28:40 2018

Revert "tast-tests: Move security.ASLR to Chrome OS Commit Queue."

This reverts commit 4f959a82747c9cc429dc1d6dc78fd9cf0d1122ff.

Reason for revert: Failing sometimes in the CQ with
"Mapping for ... occurred at ... in two maps".

Original change's description:
> tast-tests: Move security.ASLR to Chrome OS Commit Queue.
> 
> security.ASLR has been passing consistently on release
> builders since it was added, so remove its "informational"
> attribute to make it run on the Chrome OS Commit Queue.
> 
> BUG=chromium:877733
> TEST=checked results in stainless
> 
> Change-Id: I9fe73af740a80e90176d092a5a007c0c2d872646
> Reviewed-on: https://chromium-review.googlesource.com/1375273
> Commit-Ready: Dan Erat <derat@chromium.org>
> Tested-by: Dan Erat <derat@chromium.org>
> Reviewed-by: Shuhei Takahashi <nya@chromium.org>

Bug:  chromium:915824 
Change-Id: Ie76bf60498e8ae76f78a9056222df6439c825f5d
Reviewed-on: https://chromium-review.googlesource.com/c/1381060
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/c90334abfd86b9db3095a78e0e295c4feeb25490/src/chromiumos/tast/local/bundles/cros/security/aslr.go

Eric, mind figuring out what's going on here so we can add this back to the CQ?

Just bear in mind that many times this test regressed something had actually messed up ASLR.

Looks like the original test passed as long as it found one address change for each vm area under inspection, rather than requiring all of them to be different from the first run. I'll upload a CL to bring this condition in line with the original autotest and then we can talk about tightening the condition once it's reliably passing again.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/25061470ccb6a65fd79781f87ab26c35fbafd62b

commit 25061470ccb6a65fd79781f87ab26c35fbafd62b
Author: Eric Caruso <ejcaruso@chromium.org>
Date: Fri Jan 04 20:46:38 2019

security.ASLR: Relax test condition to match autotest

The test condition was accidentally strengthened during porting
so that the test would fail if any randomized address was the same
as the first iteration, rather than if all of them were. This
caused the test to flake unnecessarily.

This also does some other cleanup like combining two functions that
were only ever used in composition.

BUG= chromium:915824 
TEST=run test on nautilus

Change-Id: I578dc454e38ff60fea8a6635f64a2c43488567ae
Reviewed-on: https://chromium-review.googlesource.com/1394043
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>

[modify] https://crrev.com/25061470ccb6a65fd79781f87ab26c35fbafd62b/src/chromiumos/tast/local/bundles/cros/security/aslr.go

We should be able to add this back to the CQ now. File another bug if we want to strengthen the condition so we have to see more than 2 start addresses for all of the VM areas.