FS#56047 - chromium 62.0.3202.62-1 sandbox crashing

Attached to Project: Arch Linux
Opened by Steven Noonan (neunon) - Thursday, 19 October 2017, 13:52 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 19 October 2017, 14:14 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I did a "pacman -Syu" which moved chromium from 61.0.3163.100-1 to 62.0.3202.62-1. I was using the previous version of Chromium without any problems mere moments before upgrading. The new version doesn't seem to run proprely, even with a completely clean profile (rm -rf ~/.config/chromium ~/.cache/chromium). Running in a terminal shows a bunch of crashes occurring in the subprocesses it launches:

---
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[24418:24443:1019/064749.136824:ERROR:native_backend_kwallet_x.cc(826)] Error obtaining KWallet handle
ATTENTION: option value of option force_s3tc_enable ignored.
[1:1:1019/064749.139064:FATAL:namespace_sandbox.cc(129)] Check failed: cached_tid == *cached_tid_location (0 vs. 3)
#0 0x5576a85a7aa6 <unknown>

Received signal 6
#0 0x5576a85a7aa6 <unknown>
r8: 0000000000000000 r9: 00007ffc434d5280 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffc434d5740 r13: 0000000000000073 r14: 00007ffc434d5730 r15: 00007ffc434d5750
di: 0000000000000002 si: 00007ffc434d5280 bp: 00007ffc434d5720 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007f17aaff0880 sp: 00007ffc434d5280
ip: 00007f17aaff0880 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000010000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[24418:24448:1019/064749.140443:ERROR:zygote_communication_linux.cc(146)] Did not receive ping from zygote child
[3:3:1019/064749.140530:ERROR:zygote_linux.cc(627)] Zygote could not fork: process_type renderer numfds 6 child_pid -1
---

If I try to navigate somewhere, it shows more of the same crashes:

---
[1:1:1019/064834.860413:FATAL:namespace_sandbox.cc(129)] Check failed: cached_tid == *cached_tid_location (0 vs. 3)
#0 0x5576a85a7aa6 <unknown>

Received signal 6
#0 0x5576a85a7aa6 <unknown>
r8: 0000000000000000 r9: 00007ffc434d5280 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffc434d5740 r13: 0000000000000073 r14: 00007ffc434d5730 r15: 00007ffc434d5750
di: 0000000000000002 si: 00007ffc434d5280 bp: 00007ffc434d5720 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007f17aaff0880 sp: 00007ffc434d5280
ip: 00007f17aaff0880 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000010000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[24418:24448:1019/064834.864785:ERROR:zygote_communication_linux.cc(146)] Did not receive ping from zygote child
[3:3:1019/064834.865037:ERROR:zygote_linux.cc(627)] Zygote could not fork: process_type renderer numfds 6 child_pid -1
---

If I run with the "--no-sandbox" command-line flag, it works without any crashes but that's obviously not a safe way to run the browser, either.

Any ideas on how to debug/fix this?
This task depends upon

Closed by  Doug Newgard (Scimmia)
Thursday, 19 October 2017, 14:14 GMT
Reason for closing:  Not a bug
Comment by Doug Newgard (Scimmia) - Thursday, 19 October 2017, 13:55 GMT
What kernel?
Comment by Steven Noonan (neunon) - Thursday, 19 October 2017, 14:02 GMT
4.13.7. I wouldn't think the kernel would be relevant, though, considering the previous version of Chromium was working literally *seconds* before upgrading to the new one.
Comment by Doug Newgard (Scimmia) - Thursday, 19 October 2017, 14:04 GMT
*Specific* kernel, not just the version
Comment by Steven Noonan (neunon) - Thursday, 19 October 2017, 14:08 GMT
It's my own kernel. I tried core/linux instead and for some reason that works -- what's the magic difference here?
Comment by Doug Newgard (Scimmia) - Thursday, 19 October 2017, 14:14 GMT
Very likely related to USER_NS

Loading...