panic: vm_page_free_prep: freeing mapped page

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
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)

--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Konstantin Belousov
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 ?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
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 ?
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "[hidden email]"
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: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
In reply to this post by Konstantin Belousov
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 ?

I got a second one:
[00:02:04] Building 43 packages using 24 builders
[00:02:04] Starting/Cloning builders
[00:02:07] Hit CTRL+t at any time to see build progress and stats
[00:02:07] [01] [00:00:00] Building devel/llvm80 | llvm80-8.0.0_2
[00:02:07] [02] [00:00:00] Building lang/gcc48 | gcc48-4.8.5_10
[00:02:07] [03] [00:00:00] Building lang/gcc8 | gcc8-8.3.0_2
[00:35:48] [02] [00:33:41] Finished lang/gcc48 | gcc48-4.8.5_10: Success
[00:35:50] [02] [00:00:00] Building sysutils/uefi-edk2-bhyve |
uefi-edk2-bhyve-0.2_1,1
packet_write_wait: Connection to 2600:1700:210:b180:a6ba:dbff:fe29:6695
port 22: Broken pipe

[I] ➜ more core.txt.13
borg.lerctr.org dumped core - see /var/crash/vmcore.13

Sat Jul 13 17:38:44 CDT 2019

FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976
LER-MINIMAL  amd64

panic: freeing mapped page 0xfffff82024146980

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: freeing mapped page 0xfffff82024146980
cpuid = 4
time = 1563056884
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe03fdf757e0
vpanic() at vpanic+0x19d/frame 0xfffffe03fdf75830
panic() at panic+0x43/frame 0xfffffe03fdf75890
vm_object_collapse_scan() at vm_object_collapse_scan+0x326/frame
0xfffffe03fdf758f0
vm_object_collapse() at vm_object_collapse+0x13a/frame
0xfffffe03fdf75960
vm_object_deallocate() at vm_object_deallocate+0x4af/frame
0xfffffe03fdf759c0
vm_map_process_deferred() at vm_map_process_deferred+0x7f/frame
0xfffffe03fdf759e0
vm_map_remove() at vm_map_remove+0xc6/frame 0xfffffe03fdf75a10
vmspace_exit() at vmspace_exit+0xd8/frame 0xfffffe03fdf75a50
exit1() at exit1+0x58d/frame 0xfffffe03fdf75ac0
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe03fdf75ad0
amd64_syscall() at amd64_syscall+0x25c/frame 0xfffffe03fdf75bf0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfffffe03fdf75bf0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80112d92a, rsp =
0x7fffffffcd58, rbp = 0x7fffffffcd70 ---
Uptime: 50m59s
Dumping 11669 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  0xffffffff80764df6 in vm_object_collapse_scan (object=<optimized
out>,
     op=4) at /usr/src/sys/vm/vm_object.c:1582
#6  0xffffffff8076298a in vm_object_collapse (object=0xfffff80c6f32ba00)
     at /usr/src/sys/vm/vm_object.c:1760
#7  0xffffffff8076261f in vm_object_deallocate
(object=0xfffff80c6f32ba00)
     at /usr/src/sys/vm/vm_object.c:636
#8  0xffffffff80756aef in vm_map_entry_deallocate (entry=<optimized
out>,
     system_map=0) at /usr/src/sys/vm/vm_map.c:3457
#9  vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:586
#10 0xffffffff8075c796 in _vm_map_unlock (map=<optimized out>,
     file=<optimized out>, line=3658) at /usr/src/sys/vm/vm_map.c:599
#11 vm_map_remove (map=<optimized out>, start=4096, end=140737488355328)
     at /usr/src/sys/vm/vm_map.c:3658
#12 0xffffffff807566f8 in vmspace_dofree (vm=<optimized out>)
     at /usr/src/sys/vm/vm_map.c:335
#13 vmspace_exit (td=0xfffff81310e4a000) at /usr/src/sys/vm/vm_map.c:416
#14 0xffffffff80476dbd in exit1 (td=0xfffff81310e4a000, rval=<optimized
out>,
     signo=0) at /usr/src/sys/kern/kern_exit.c:417
#15 0xffffffff8047682d in sys_sys_exit (td=<unavailable>, uap=<optimized
out>)
     at /usr/src/sys/kern/kern_exit.c:195
#16 0xffffffff807adaac in syscallenter (td=0xfffff81310e4a000)
     at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#17 amd64_syscall (td=0xfffff81310e4a000, traced=0)
     at /usr/src/sys/amd64/amd64/trap.c:1181
#18 <signal handler called>
#19 0x000000080112d92a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffcd58
(kgdb)
--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Mark Johnston-2
In reply to this post by Konstantin Belousov
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?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Konstantin Belousov
On Sun, Jul 14, 2019 at 03:34:20PM -0400, Mark Johnston wrote:

> 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,
The eflags value is slightly strange.

>   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
What is the object type ?  Can you please print the object(s) ?

>
> 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?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Mark Johnston-2
On Sun, Jul 14, 2019 at 11:03:54PM +0300, Konstantin Belousov wrote:

> On Sun, Jul 14, 2019 at 03:34:20PM -0400, Mark Johnston wrote:
> > 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,
> The eflags value is slightly strange.

Yeah, I'd expect MAP_ENTRY_COW.

> >   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
> What is the object type ?  Can you please print the object(s) ?

OBJT_DEFAULT.

$34 = {                                                                                                                                                                      
  lock = {                                                                                                                                                                    
    lock_object = {                                                                                                                                                          
      lo_name = 0xffffffff808571d4 "vm object",                                                                                                                              
      lo_flags = 627245056,                                                                                                                                                  
      lo_data = 0,                                                                                                                                                            
      lo_witness = 0x0                                                                                                                                                        
    },                                                                                                                                                                        
    rw_lock = 18446735366207213568                                                                                                                                            
  },                                                                                                                                                                          
  object_list = {                                                                                                                                                            
    tqe_next = 0xfffff80bbeb94500,                                                                                                                                            
    tqe_prev = 0xfffff80bbeb94320                                                                                                                                            
  },                                                                                                                                                                          
  shadow_head = {                                                                                                                                                            
    lh_first = 0xfffff8066f43b600                                                                                                                                            
  },                                                                                                                                                                          
  shadow_list = {                                                                                                                                                            
    le_next = 0xfffff815ca45de00,                                                                                                                                            
    le_prev = 0xfffff80665064438                                                                                                                                              
  },                                                                                                                                                                          
  memq = {                                                                                                                                                                    
    tqh_first = 0xfffff81faf7ecbb0,                                                                                                                                          
    tqh_last = 0xfffff81fb1719ec0                                                                                                                                            
  },                                                                                                                                                                          
  rtree = {                                                                                                                                                                  
    rt_root = 18446735385885095616                                                                                                                                            
  },                                                                                                                                                                          
  size = 37995,                                                                                                                                                              
  domain = {                                                                                                                                                                  
    dr_policy = 0x0,                                                                                                                                                          
    dr_iter = 0                                                                                                                                                              
  },                                                                                                                                                                          
  generation = 1,                                                                                                                                                            
  ref_count = 0,                                                                                                                                                              
  shadow_count = 5,                                                                                                                                                          
  memattr = 6 '\006',                                                                                                                                                        
  type = 0 '\000',                                                                                                                                                            
  flags = 4104,                                                                                                                                                              
  pg_color = 5632,                                                                                                                                                            
  paging_in_progress = 0,                                                                                                                                                    
  resident_page_count = 26097,                                                                                                                                                
  backing_object = 0x0,                                                                                                                                                      
  backing_object_offset = 0,
  pager_object_list = {
    tqe_next = 0x0,
    tqe_prev = 0x0
  },
  rvq = {
    lh_first = 0x0
  },
  handle = 0x0,
  un_pager = {
    vnp = {
      vnp_size = 81,
      writemappings = 0
    },
    devp = {
      devp_pglist = {
        tqh_first = 0x51,
        tqh_last = 0x0
      },
      ops = 0x0,
      dev = 0x0
    },
    sgp = {
      sgp_pglist = {
        tqh_first = 0x51,
        tqh_last = 0x0
      }
    },
    swp = {
      swp_tmpfs = 0x51,
      swp_blks = {
        pt_root = 0
      }
    }
  },
  cred = 0xfffff8104e939600,
  charge = 149336064,
  umtx_data = 0x0
}
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
I got another panic overnight while my bacula backups were running.  
It's
probably postgres again.

Mark,
    I've uploaded the dump/core.txt, info file to the same place on
freefall (*17*).

What else can I provide to help find this bug and eradicate it.



--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Mark Johnston-2
On Mon, Jul 15, 2019 at 07:53:43AM -0500, Larry Rosenman wrote:
> I got another panic overnight while my bacula backups were running.  
> It's
> probably postgres again.
>
> Mark,
>     I've uploaded the dump/core.txt, info file to the same place on
> freefall (*17*).
>
> What else can I provide to help find this bug and eradicate it.

What's the last known good revision for this system?  That is, at what
revision was the last kernel where you didn't see the problem on this
system?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
On 07/15/2019 10:14 am, Mark Johnston wrote:

> On Mon, Jul 15, 2019 at 07:53:43AM -0500, Larry Rosenman wrote:
>> I got another panic overnight while my bacula backups were running.
>> It's
>> probably postgres again.
>>
>> Mark,
>>     I've uploaded the dump/core.txt, info file to the same place on
>> freefall (*17*).
>>
>> What else can I provide to help find this bug and eradicate it.
>
> What's the last known good revision for this system?  That is, at what
> revision was the last kernel where you didn't see the problem on this
> system?

r349858 on 2019-07-09.
--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Mark Johnston-2
In reply to this post by Larry Rosenman
On Mon, Jul 15, 2019 at 07:53:43AM -0500, Larry Rosenman wrote:
> I got another panic overnight while my bacula backups were running.  
> It's
> probably postgres again.
>
> Mark,
>     I've uploaded the dump/core.txt, info file to the same place on
> freefall (*17*).
>
> What else can I provide to help find this bug and eradicate it.

Just to follow up, the panic should be resolved by r350005.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
On 07/15/2019 3:53 pm, Mark Johnston wrote:

> On Mon, Jul 15, 2019 at 07:53:43AM -0500, Larry Rosenman wrote:
>> I got another panic overnight while my bacula backups were running.
>> It's
>> probably postgres again.
>>
>> Mark,
>>     I've uploaded the dump/core.txt, info file to the same place on
>> freefall (*17*).
>>
>> What else can I provide to help find this bug and eradicate it.
>
> Just to follow up, the panic should be resolved by r350005.

Updated to r350011.  We'll see how it does.  Thank You for
looking at it.

--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: panic: vm_page_free_prep: freeing mapped page

Larry Rosenman
On 07/15/2019 5:10 pm, Larry Rosenman wrote:

> On 07/15/2019 3:53 pm, Mark Johnston wrote:
>> On Mon, Jul 15, 2019 at 07:53:43AM -0500, Larry Rosenman wrote:
>>> I got another panic overnight while my bacula backups were running.
>>> It's
>>> probably postgres again.
>>>
>>> Mark,
>>>     I've uploaded the dump/core.txt, info file to the same place on
>>> freefall (*17*).
>>>
>>> What else can I provide to help find this bug and eradicate it.
>>
>> Just to follow up, the panic should be resolved by r350005.
>
> Updated to r350011.  We'll see how it does.  Thank You for
> looking at it.
Well, it made it through the pgbuildfarm run.  I think we're good.

Thanks, all!
--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [hidden email]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"