Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: try KMGUARD and debug_freecheck=1

Manuel Bouyer <> wrote:
> > I tried on a amd64 host with 8GB RAM (looks like I expanded the i386
> > tests.tgz instead of amd64 but it shouldn't matter). I got a panic
> > while running the stress_long test, but not from kmemguard
> > unforntunably:
> And another one:
> login: uvm_fault(0xffffffff80e7c960, 0xffff800015787000, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip ffffffff80113f8e cs 8 rflags 10206 cr2
> ffff800015787000 cpl 0 rsp fffffe810c72fa28 kernel: page fault trap,
> code=0 Stopped in pid 1063.4 (h_reconcli) at   netbsd:copystr+0xe:
> lodsb   (%rsi) db{6}> tr
> copystr() at netbsd:copystr+0xe
> unp_connect() at netbsd:unp_connect+0x90
> uipc_usrreq() at netbsd:uipc_usrreq+0x238
> do_sys_connect() at netbsd:do_sys_connect+0x8d
> sys_connect() at netbsd:sys_connect+0x38
> syscall() at netbsd:syscall+0xac

This looks like potentially a real bug found by KMGUARD.  I have not had
time to inspect the code yet..  Keep in mind that KMGUARD forces defective
code (e.g. which overruns a buffer or uses the memory after free) at the
moment it does that.

Also, there is another debugging facility.  Try setting debug_freecheck
to 1 early in DDB.  I wonder if we are doing good enough job in catching
wrong kmem_free() arguments.


Home | Main Index | Thread Index | Old Index