Date: Sun, 14 Jul 2019 15:34:20 -0400 From: Mark Johnston <markj@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Larry Rosenman <ler@lerctr.org>, Freebsd current <freebsd-current@freebsd.org> Subject: Re: panic: vm_page_free_prep: freeing mapped page Message-ID: <20190714193420.GC82719@raichu> In-Reply-To: <20190713221457.GP47193@kib.kiev.ua> References: <f4786e0de2fcc40ea3d0341a166a8320@lerctr.org> <20190713221457.GP47193@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 14, 2019 at 01:14:57AM +0300, Konstantin Belousov wrote:
> On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote:
> > I have cores. Ideas?
> > svn rev: r349976
> >
> > [I] ➜ more core.txt.12
> > borg.lerctr.org dumped core - see /var/crash/vmcore.12
> >
> > Sat Jul 13 16:47:03 CDT 2019
> >
> > FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976
> > LER-MINIMAL amd64
> >
> > panic: vm_page_free_prep: freeing mapped page 0xfffff82031044790
>
> What was the process which caused the panic ? Was it threaded ?
I looked at some of the kernel dumps. In all cases the crashing process
is postgres. We have:
(kgdb) p/x *m->md.pv_list.tqh_first
$20 = {
pv_va = 0x801c00000,
pv_next = {
tqe_next = 0xfffff80b3aacb568,
tqe_prev = 0xfffff81faf7ecbe8
}
}
(kgdb) p/x *m->md.pv_list.tqh_first->pv_next.tqe_next
$21 = {
pv_va = 0x801c00000,
pv_next = {
tqe_next = 0x0,
tqe_prev = 0xfffff80b3ab905d0
}
}
We can find the corresponding pmaps for these mappings by going
through the corresponding pv_chunks. Then I looked up the other
processes with mappings of the page. They are also postgres processes.
We have:
$33 = {
prev = 0xfffff818baa2be00,
next = 0xfffff80e7e9875b0,
left = 0xfffff814df7a6310,
right = 0xfffff80e7e9875b0,
start = 0x801c00000,
end = 0x80aa4a000,
next_read = 0x801c00000,
max_free = 0x3000,
object = {
vm_object = 0xfffff80bbeb94400,
sub_map = 0xfffff80bbeb94400
},
offset = 0x600000,
eflags = 0x0,
protection = 0x3,
max_protection = 0x7,
inheritance = 0x0,
read_ahead = 0xf,
wired_count = 0x0,
cred = 0x0,
wiring_thread = 0x0
}
and
(kgdb) p $33->object.vm_object->ref_count
$34 = 0
(kgdb) p $33->object.vm_object->shadow_count
$35 = 5
So it seems that there is some problem with vm_object reference
counting; I'd expect a vm_map_entry reference to be counted in the
ref_count field, and we have at least two such references.
Larry, could you open a bugzilla PR for this panic?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190714193420.GC82719>