Comment # 25 on bug 1156336 from Aleksa Sarai

(In reply to Matei Albu from comment #24)
> Created attachment 828578 [details]
> lxd strace
> 
> Here's the strace output. I'm gonna provide delve output soon.

Okay, so a quick look (I'll take a better look tomorrow morning) indicates that
the segfault we see in the coredump happens here -- the go runtime is killing
itself:

22299 rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
22299 rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=~[],
sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f42572fd300}, NULL, 8) = 0
22299 gettid()                          = 22299
22299 tkill(22299, SIGSEGV)             = 0
22299 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=22286, si_uid=0}
---

But there is an earlier segfault:

22299 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0 <unfinished ...>
22286 epoll_pwait(4,  <unfinished ...>
22299 <... mmap resumed> )              = 0x7f424ac9c000
22299 mprotect(0x7f4224021000, 24576, PROT_READ|PROT_WRITE) = 0
22299 mprotect(0x7f4224027000, 86016, PROT_READ|PROT_WRITE) = 0
22299 getpid()                          = 22286
22299 openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 17
22299 read(17,
"lD\332\352\365\277C\304\36\16u!\306\241O\331@\335\17\314\340\302\352$\373\226\257\23\261\331\335!"...,
256) = 256
22299 close(17)                         = 0
22299 mprotect(0x7f422403c000, 4096, PROT_READ|PROT_WRITE) = 0
22299 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---

Now, I don't think you can get a segfault from mprotect() -- but fact that
si_code=SI_KERNEL indicates that the kernel initiated the segfault (if the
issue was access within an mprotect() region you should get SI_USER along with
a meaningful si_addr).