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:
(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):
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.
Received signal 4 ILL_ILLOPN
The OpenEmbedded report of Chromium no longer working when built against glibc 2.24:
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:
And to be clear, yes, we have tested the Fedora chromium package and it crashed in the way described above, which is why I filed this bug.
*** This bug has been marked as a duplicate of bug 1361157 ***