Description of problem:
Chromium crashes in Fedora 25 and Rawhide with a backtrace such as:
Received signal 4 ILL_ILLOPN 7f58262eac90
#0 0x7f58266a864e <unknown>
…
(Ignore the addresses above, those are actually from QtWebEngine, I don't have a Chromium backtrace saved right now.)

This happens because the packages there are built at compile time against glibc 2.25, which defines the MADV_FREE macro. So the memory allocation code in "WTF" (a part of WebKit/Blink) tries to use that instead of MADV_DONTNEED, but the sandbox only allows MADV_DONTNEED.

QtWebEngine upstream now carries this fix:
http://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=49-based&id=b12ffcd411d4776f7120ccecb3be34344d930d2b
(which is misleadingly/incompletely labeled in the commit message – even if you have a new enough kernel, as we do, MADV_FREE is not going to work because the sandbox does not allow it). I backported that to my QtWebEngine packaging. But, since Chromium crashes with the same backtrace, it also needs some version of this fix. (Unfortunately, the Qt patch is only in 49-based so far, not in one of the branches based on a newer Chromium.)

Version-Release number of selected component (if applicable):
chromium-52.0.2743.116-1.fc25
chromium-52.0.2743.116-1.fc26

How reproducible:
Always

Steps to Reproduce:
1. Boot a F25/Rawhide Live image.
2. dnf install chromium
3. sudo setenforce 0 to work around bug #1363914
4. sudo chmod a+w /dev/shm to work around bug #1347436
5. Try starting chromium.

Actual results:
Received signal 4 ILL_ILLOPN

Expected results:
No crash.

Additional info:
The OpenEmbedded report of Chromium no longer working when built against glibc 2.24:
https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg82915.html

The QtWebEngine Fedora bug where I debugged that (with the help of Florian Weimer) to find all the details I am providing in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1364781