Web browser can't browse anything - "The rendering process has been closed for this tab" [signal 4 ILL_ILLOPN]

The failure appears to be in oxide itself. Have you done a rebuild of oxide against the new glibc?

No, this was just an observation of a webbrowser-app rebuild. But at the time of when I reported this bug, there already was a new oxide-qt built in yakkety which was built against the new glibc.

Timo confirms that a simple Oxide webview in qmlscene exhibits the same issue with yakkety-proposed, so it’s not a webbrowser-app issue.

This appears to be the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1366894.

There's a couple of issues here:

- The new glibc defines MADV_FREE which Chromium detects at compile-time and results in a runtime dependency on it. However, this was only added to linux 4.5.
- The seccomp sandbox doesn't allow madvise(MADV_FREE), which is likely what this crash is.

https://git.launchpad.net/~oxide-developers/oxide/+git/chromium/commit/?id=eb8fa3da863983d891bbfde32ff52e8344f8c48c should do it

https://git.launchpad.net/~oxide-developers/oxide/+git/oxide/commit/?h=crmaster&id=1b77aedc83aec699f58bfe1359c233aabfdbcb54

Marking the glibc task as invalid (see IRC conversation)

<chrisccoulson> does the kernel in yakkety support MADV_FREE?
<apw> chrisccoulson, that is documented as 4.5+ so we will, and currently don't
<chrisccoulson> apw, ah thanks. See bug 1613258 for context - the new glibc defines MADV_FREE
<apw> chrisccoulson, that may have been built with the 4.6 which was in -proposed for a time (glibc)
<apw> that said, i am supprised that glibc is assuming it can use it
 infinity, ^
<apw> chrisccoulson, oh but it is likely the seccomp bits right? so just a profile change ?
 chrisccoulson, in the sense it is resonable for glibc to define it, and the kernel to return EINVAL or indeed work, but we need the seccomp profile to reflect that possibility
<chrisccoulson> apw, we'll probably end up doing the same as http://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=49-based&id=b12ffcd411d4776f7120ccecb3be34344d930d2b
<apw> chrisccoulson, wouldn't it make more sense to try MADV_FREE and if it fails ENOSUPPORT or whatever dropback to whatever it does when it doesn't have _FREE ?
<apw> so one uses it in 4.5 and not before that all shiney and automatically
<chrisccoulson> apw, we could probably do that

What's the Ubuntu package name we're expecting a fix in?

The source package is oxide-qt.

This bug was fixed in the package oxide-qt - 1.16.9-0ubuntu1

---------------
oxide-qt (1.16.9-0ubuntu1) yakkety; urgency=medium

  * Update to v1.16.9
    - Fix LP: #1601887 - Add a quirk to assume that the native orientation of
      the primary screen on freiza and cooler devices is landscape
    - Fix LP: #1613258 - Avoid a hard runtime dependency on MADV_FREE when
      compiled against glibc 2.24, and ensure madvise(MADV_FREE) is allowed
      in the seccomp policy so that it works when the kernel is upgraded to 4.5
    - Fix LP: #1616132 - Explicitly whitelist accelerated canvas and GPU
      raster on various devices. This got disabled due to a recent change
      in libhybris

 -- Chris Coulson <email address hidden> Wed, 24 Aug 2016 16:46:54 +0100

Now starts up and appears to work fine, but then fails again soon after loading 'news.google.com' ...

  The rendering process has been closed for this tab

@Daniel: are you seeing anything useful in the app’s logs?
Any crash file?

I can confirm that the browser tab crashes soon after loading news.google.com with current yakkety amd64 live iso.

That seems to be a different bug

The new bug is bug 1618589. Would be great if someone could investigate that.