On Fri, Jul 26, 2019 at 12:57:23AM +0200, Alexander Bluhm wrote:
> On Wed, Jul 24, 2019 at 03:22:31PM -0700, Mike Larkin wrote:
> > If this happens again, it might be interesting to see what pages around
> > that are mapped.
>
> They are not mapped.
>
> uvm_fault(0xffffffff81da8270, 0x7f826ae62830, 0, 2) -> e
> kernel: page fault trap, code=0
> Stopped at pmap_page_remove+0x210: xchgq %rax,0(%rcx,%rdx,1)
> ddb{0}> trace
> pmap_page_remove(fffffd810b60de00) at pmap_page_remove+0x210
> uvm_anfree(fffffd816a8396d0) at uvm_anfree+0x36
> amap_wipeout(fffffd827f101138) at amap_wipeout+0xe5
> uvm_unmap_detach(ffff800021eba398,1) at uvm_unmap_detach+0xef
> uvm_map_teardown(fffffd823df509a0) at uvm_map_teardown+0x1c1
> uvmspace_free(fffffd823df509a0) at uvmspace_free+0x57
> uvm_exit(ffff800021eee038) at uvm_exit+0x24
> reaper(ffff8000ffff89e8) at reaper+0x13b
> end trace frame: 0x0, count: -8
>
> ddb{0}> x/x 0x7f826ae62000
> 0x7f826ae62000:uvm_fault(0xffffffff81da8270, 0x7f826ae62000, 0, 1) -> e
> kernel: page fault trap, code=0
> Faulted in DDB; continuing...
> ddb{0}> x/x 0x7f826ae61000
> 0x7f826ae61000:uvm_fault(0xffffffff81da8270, 0x7f826ae61000, 0, 1) -> e
> kernel: page fault trap, code=0
> Faulted in DDB; continuing...
> ddb{0}> x/x 0x7f826ae63000
> 0x7f826ae63000:uvm_fault(0xffffffff81da8270, 0x7f826ae63000, 0, 1) -> e
> kernel: page fault trap, code=0
> Faulted in DDB; continuing...
>
> Note that /usr/src/regress/lib/libpthread/malloc_duel/malloc_duel.c
> does allocations in small malloc(sizeof(int)) chunks. So I think
> we are dealing with random page size mappings.
>
> bluhm
>
Probably time to start bisecting the tree to find out when this error
was introduced. The information above wasn't too enlightening (although I
really didn't think it would be...)
-ml
