On Mon, Jun 13, 2016 at 08:42:35AM -0700, Philip Guenther wrote:
> On Sun, 12 Jun 2016, Dimitris Papastamos wrote:
> > I was building ports and at the same time started chromium and the
> > kernel panic-ed.
> >
> > This has happened a few times in the last week. It started happening at
> > some point towards the end of May. It is not easy to reproduce locally.
>
> Thank you for the report! When you say "not easy to reproduce locally",
> do you mean you _can_ semireliably reproduce it, such that if we found a
> suspicious commit to revert you would be able to be pretty sure whether it
> was really fixed? If so, what's your best guess on how to tickle it?
Hi,
I had a look at this. I am currently exploring the possibility that
the crash could be due to this patch from May 26th 2016:
"Make amaps use less kernel memory (2nd try)"
Not verified this yet in any way, just thought I would post early in
case anyone has any ideas.
I also reviewed the patch from Aug 28th 2015:
"Rework the UNIX domain socket garbage collector, including ideas from
{Free,Net}BSD"
but I did not see an issue with it. In the trace that I posted it
seems to crash on line 905 in unp_gc() in sys/kern/uipc_usrreq.c:
899 /* close any fds on the deferred list */
900 while ((defer = SLIST_FIRST(&unp_deferred)) != NULL) {
901 SLIST_REMOVE_HEAD(&unp_deferred, ud_link);
902 for (i = 0; i < defer->ud_n; i++) {
903 memcpy(&fp, &((struct file **)(defer + 1))[i],
904 sizeof(fp));
905 FREF(fp); <-- here
906 if ((unp = fptounp(fp)) != NULL)
907 unp->unp_msgcount--;
908 unp_rights--;
909 (void) closef(fp, NULL);
910 }
911 free(defer, M_TEMP, sizeof(*defer) + sizeof(fp) *
defer->ud_n);
912 }
The address that it crashes on seems to be aligned and not fiddled
with. So I suspect memory was unmapped and later on triggered a uvm
fault when accessed via FREF().
