Re: panic: vm_page_free_prep: freeing mapped page

From: Larry Rosenman <ler_at_lerctr.org>
Date: Sat, 13 Jul 2019 17:16:30 -0500
On 07/13/2019 5:14 pm, 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
>> 
>> GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
>> Copyright (C) 2019 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-portbld-freebsd13.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>>      <http://www.gnu.org/software/gdb/documentation/>.
>> 
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /boot/kernel/kernel...
>> Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...
>> 
>> Unread portion of the kernel message buffer:
>> panic: vm_page_free_prep: freeing mapped page 0xfffff82031044790
>> cpuid = 21
>> time = 1563053382
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe018f9fd890
>> vpanic() at vpanic+0x19d/frame 0xfffffe018f9fd8e0
>> panic() at panic+0x43/frame 0xfffffe018f9fd940
>> vm_page_free_prep() at vm_page_free_prep+0x18a/frame 
>> 0xfffffe018f9fd960
>> vm_page_free_toq() at vm_page_free_toq+0x12/frame 0xfffffe018f9fd990
>> vm_object_terminate() at vm_object_terminate+0x1db/frame
>> 0xfffffe018f9fd9e0
>> vm_object_deallocate() at vm_object_deallocate+0x412/frame
>> 0xfffffe018f9fda40
>> vm_map_process_deferred() at vm_map_process_deferred+0x7f/frame
>> 0xfffffe018f9fda60
>> kern_munmap() at kern_munmap+0x181/frame 0xfffffe018f9fdad0
>> amd64_syscall() at amd64_syscall+0x25c/frame 0xfffffe018f9fdbf0
>> fast_syscall_common() at fast_syscall_common+0x101/frame
>> 0xfffffe018f9fdbf0
>> --- syscall (73, FreeBSD ELF64, sys_munmap), rip = 0x80119978a, rsp =
>> 0x7fffffffce18, rbp = 0x7fffffffce20 ---
>> Uptime: 2h27m22s
>> Dumping 15640 out of 131026
>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>> 
>> __curthread () at /usr/src/sys/amd64/include/pcpu.h:246
>> 246             __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
>> (OFFSETOF_CURTHREAD));
>> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu.h:246
>> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
>> #2  0xffffffff804b6620 in kern_reboot (howto=260)
>>      at /usr/src/sys/kern/kern_shutdown.c:479
>> #3  0xffffffff804b6a99 in vpanic (fmt=<optimized out>, ap=<optimized
>> out>)
>>      at /usr/src/sys/kern/kern_shutdown.c:905
>> #4  0xffffffff804b67d3 in panic (fmt=<unavailable>)
>>      at /usr/src/sys/kern/kern_shutdown.c:832
>> #5  0xffffffff8076c21a in vm_page_free_prep (m=0xfffff82031044790)
>>      at /usr/src/sys/vm/vm_page.c:3273
>> #6  0xffffffff80768152 in vm_page_free_toq (m=0xfffff82031044790)
>>      at /usr/src/sys/vm/vm_page.c:3483
>> #7  0xffffffff8076321b in vm_object_terminate_pages (object=<optimized
>> out>)
>>      at /usr/src/sys/vm/vm_object.c:726
>> #8  vm_object_terminate (object=0xfffff81b924c9600)
>>      at /usr/src/sys/vm/vm_object.c:798
>> #9  0xffffffff80762582 in vm_object_deallocate
>> (object=0xfffff81b924c9600)
>>      at /usr/src/sys/vm/vm_object.c:663
>> #10 0xffffffff80756aef in vm_map_entry_deallocate (entry=<optimized
>> out>,
>>      system_map=0) at /usr/src/sys/vm/vm_map.c:3457
>> #11 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:586
>> #12 0xffffffff807606b1 in kern_munmap (td=0xfffff80c207e0000,
>>      addr0=<optimized out>, size=149200896) at
>> /usr/src/sys/vm/vm_mmap.c:603
>> #13 0xffffffff807adaac in syscallenter (td=0xfffff80c207e0000)
>>      at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
>> #14 amd64_syscall (td=0xfffff80c207e0000, traced=0)
>>      at /usr/src/sys/amd64/amd64/trap.c:1181
>> #15 <signal handler called>
>> #16 0x000000080119978a in ?? ()
>> Backtrace stopped: Cannot access memory at address 0x7fffffffce18
>> (kgdb)
> 
> What was the process which caused the panic ?  Was it threaded ?
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe_at_freebsd.org"
It was a poudriere run, so I don't know for sure.


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler_at_lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Received on Sat Jul 13 2019 - 20:16:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC