On Mon, Oct 14, 2019 at 04:17:53PM +0200, Alexander Bluhm wrote:
> On Fri, Oct 11, 2019 at 01:19:02PM +0000, L??vai, D??niel wrote:
> > uvm_fault(0xfffffd8124d90960, 0x7f884cecdcf8, 0, 2) -> e
> > kernel: page fault trap, code=0
> > Stopped at pmap_page_remove+0x210: xchgq %rax,0(%rcx,%rdx,1)
>
> > ddb{3}> trace
> > pmap_page_remove(fffffd800975d480) at pmap_page_remove+0x210
> > uvm_anfree(fffffd8125d62b10) at uvm_anfree+0x36
> > amap_wipeout(fffffd8123d95170) at amap_wipeout+0xe5
> > uvm_unmap_detach(ffff800022420fe8,0) at uvm_unmap_detach+0x90
> > sys_munmap(ffff800022233cb8,ffff800022421060,ffff8000224210d0) at
> > sys_munmap+0x11d
> > syscall(ffff800022421140) at syscall+0x305
> > Xsyscall(6,49,109a8d931e10,49,109a58e72150,1099d9b9f000) at Xsyscall+0x128
> > end of kernel
> > end trace frame: 0x109a82dffa50, count: -7
>
> I see this bug for a while now.
>
> https://marc.info/?l=openbsd-bugs&m=156399483018833&w=2
>
> I can trigger it by running /usr/src/regress/lib/libpthread/malloc_duel
> for some hours. Moritz Buhl has tried to bisect the problem and
> it appears to exists since January 2019. But it is hard to be sure
> as reproducing takes a while. It is also unclear whether the change
> in behavior is caused by compiler, kernel, libc, libpthread or
> malloc_duel. We could not trigger it with OpenBSD 6.4.
>
> bluhm
>
There's been a change in malloc_duel to use more threads. Originally
it was using 2, now 11. That change was committed in May 2019 (plus a
commit to enable the test), so later than Jan 2019. But a userland
induced panic is always a bug.
-Otto
