I've recently been getting tab crashes while visiting sites like html5test.com on Linux. Here's a typical crash report: https://crash-stats.mozilla.com/report/index/f5ef25ce-5956-4ae5-a0fc-5d1d70170805 Mozregression points the finger at bug 1308400. I've attached the raw data from about:support just in case it helps.

You can run with MOZ_SANDBOX_LOGGING=1 and see if there's anything interesting in the console when it crashes. It's SIGTRAP not SIGSYS, which is somewhat interesting, and may narrow down things a bit.

Thanks! It appears to be unable to open dconf, so this would appear to be a dupe of bug 1384986. I've attached the log just in case, but will close this ticket. PS: Note that I won't be at this computer for the next week.

I am not sure. The dconf issue could cause issues with sound, but it's non-fatal, and your graphics drivers are failing to load: libGL error: unable to load driver: nouveau_dri.so libGL error: driver pointer missing libGL error: failed to load driver: nouveau ... libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast (swrast is the fallback for nouveau) It's not clear to me why this happens, from the log.

This sounds vaguely like bug 1290896 (expected driver failed to load, swrast crashed due to LLVM bug), but I think the problem might be here: Sandbox: SandboxBroker: denied op=open rflags=2000000 perms=0 path=/usr/lib64/../lib64/libtinfo.so.6 for pid=3709 Sandbox: Failed errno -13 op 0 flags 02000000 path /usr/lib64/../lib64/libtinfo.so.6 We should be allowing /usr/lib64 (recursively), but that .. might be causing problems.

Could you run "realpath /usr/lib64" and "realpath /usr/lib64/../lib64/libtinfo.so.6" and comment with the output? I have an idea about what's going on here. If /usr/lib64 is symlinked to something we're not currently allowing (e.g., /lib64), then that would explain everything we're seeing: the canonicalized path isn't allowed, and it won't inherit the symlink's read permissions because of the "..". But if /usr/lib64 is a regular directory and /usr/lib64/libtinfo.so.6 is a symlink to somewhere outside /usr/lib64, then something went wrong with the symlink permission logic, because that should have been allowed. In either case, /usr/lib64/libtinfo.so.6 would have worked, because we don't try to canonicalize the path if it doesn't contain "..". And, for reference, that mysterious "/../lib64" is almost certainly from the DT_RPATH attribute on libLLVM.so ("readelf -d" will show that).

Ah, nice idea jld! I got these results: >$ realpath /usr/lib64 >/usr/lib64 > >$ realpath /usr/lib64/../lib64/libtinfo.so.6 >/usr/lib64/libtinfo.so.6 However, this path didn't actually exist on my system: /usr/lib64/libtinfo.so.6 Yet this did: /lib64/libtinfo.so.6 So I just made a symlink from /lib64/libtinfo.so.6 to /usr/lib64/libtinfo.so.6, and now the crashes are gone.

From discussion in the meeting, the ld.so manpage says: In the default path /lib, and then /usr/lib. (On some 64-bit architectures, the default paths for 64-bit shared objects are /lib64, and then /usr/lib64. We cover these: policy->AddDir(rdonly, "/lib"); policy->AddDir(rdonly, "/usr/lib"); policy->AddDir(rdonly, "/usr/lib32"); policy->AddDir(rdonly, "/usr/lib64"); Meaning that /lib64 is missing.

Comment on attachment 8898352 [details] Bug 1387742 - Whitelist default dynamic linker paths, including /lib64. https://reviewboard.mozilla.org/r/169722/#review175036

Pushed by gpascutto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0d0513f1bb45 Whitelist default dynamic linker paths, including /lib64. r=jld