This isn't recent.  It's been doing it since the beginning and it's a natural side effect of tests that test its resilience to corrupted memory.

If it's recent for a particular test then it's that test.

Or I could just remove the log message.  It's important in that something bad is going on...  but unlikely that anybody will ever see it.

> This isn't recent.  It's been doing it since the beginning and it's a natural side effect of tests that test its resilience to corrupted memory.

Note that is not a base_unittest. This is a layout test. Which part of layout test exercise the resilience to corrupted memory?

> Or I could just remove the log message.  It's important in that something bad is going on...  but unlikely that anybody will ever see it.

If something is a real error, why not crashing with a CHECK() (and have a DEATH test).
Who is going to ever read log messages? They just cause spam.
The reliable way to get these signals is to cause a crash and get reports on crash/.

I only noticed since it started popping up in various local builds. Primiano mentioned he's seeing it on bots too.

I wanted to open the bug since the error sounds pretty scary, but I'm not sure what to do about it.

If it's not base, then something bad is likely going on.  Memory should not be corrupted except by the intentional test in base/.

What test is being run when these messages occur?

The PersistentMemoryAllocator is thread-secure (because it can share memory with untrusted processes like the Renderer) and so is resilient to crashes due to corruption.  Reporting is fine; crashing is not.

In my case message is coming out of Content Shell, i.e., not even a test. To reproduce:

$ ninja -C out/Release content_shell
ninja: Entering directory `out/Release'
[3/22] SOLINK ./libblink_core.so
$ out/Release/content_shell
...
[14328:14328:1209/175559.707121:1489865874045:ERROR:persistent_memory_allocator.cc(705)] Corruption detected in shared-memory segment.

(This is on Linux at rev #436912)

It's also possible this is related to the shared memory field trial sharing work by Lawrence that's been recently enabled on Linux.

Anything using the allocator that writes outside of an allocated block could cause this, yes.

Did anybody learn anything about what test was causing the problem and/or do a bisection to determine when this log message started appearing?

No test outside of those specific to PersistentMemoryAllocator should show that error so without further information, I'm going to have to assume that this is doing its job and warning of a memory trampler somewhere.

Did anybody try the repro skyostil provided in #5 ?

I don't have an active Linux development environment so can't try it myself.

Can we narrow down to what layout tests trigger this?

If it's indeed a memory stomper, then it sounds like the web platform team that owns the layout tests should investigate. Assigning back to skyostil@ since he has a repro, but not sure if there's a better owner or triage queue for web platform to take this.

From #5 this is not related with layout tests, and the issue shows just opening content_shell.
Can somebody with a Linux workstation check that it's still the case?

Not seeing this anymore at ToT (tried layout tests, headless shell and content shell).