The following reply was made to PR port-i386/36475; it has been noted by GNATS.

From: Pavel Cahyna <pavel@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: port-i386-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org
Subject: Re: port-i386/36475: uvm_fault() in process exit code
Date: Wed, 13 Jun 2007 00:39:34 +0200

 On Tue, Jun 12, 2007 at 09:50:00AM +0000, he@NetBSD.org wrote:
 > 	Disassembly of pmap_activate() reveals:
 > 
 > (gdb) x/20i pmap_activate
 > 0xc0467c7c <pmap_activate>:     push   %ebp
 > 0xc0467c7d <pmap_activate+1>:   mov    %esp,%ebp
 > 0xc0467c7f <pmap_activate+3>:   sub    $0x8,%esp
 > 0xc0467c82 <pmap_activate+6>:   mov    0x8(%ebp),%edx
 > 0xc0467c85 <pmap_activate+9>:   mov    %fs:0x4,%ecx
 > 0xc0467c8c <pmap_activate+16>:  mov    0x10(%edx),%eax
 > 0xc0467c8f <pmap_activate+19>:  mov    0x1c(%eax),%eax
 > 0xc0467c92 <pmap_activate+22>:  cmp    0x14(%ecx),%edx
 > 0xc0467c95 <pmap_activate+25>:  mov    (%eax),%eax
 > 0xc0467c97 <pmap_activate+27>:  je     0xc0467c9c <pmap_activate+32>
 > 0xc0467c99 <pmap_activate+29>:  leave  
 > 0xc0467c9a <pmap_activate+30>:  ret    
 > 0xc0467c9b <pmap_activate+31>:  nop    
 > 0xc0467c9c <pmap_activate+32>:  cmpl   $0x0,0xc0(%ecx)
 > 0xc0467ca3 <pmap_activate+39>:  jne    0xc0467cef <pmap_activate+115>
 > 0xc0467ca5 <pmap_activate+41>:  cmpl   $0x0,0xc4(%ecx)
 > 0xc0467cac <pmap_activate+48>:  je     0xc0467cd6 <pmap_activate+90>
 > 0xc0467cae <pmap_activate+50>:  cmp    $0xc08d8780,%eax
 > 0xc0467cb3 <pmap_activate+55>:  je     0xc0467cca <pmap_activate+78>
 > 0xc0467cb5 <pmap_activate+57>:  mov    0x5c(%eax),%eax
 > (gdb) x/20i
 > 0xc0467cb8 <pmap_activate+60>:  mov    0x74(%edx),%edx
 > 0xc0467cbb <pmap_activate+63>:  mov    %eax,0x60(%edx)
 > 0xc0467cbe <pmap_activate+66>:  movl   $0x1,0xc0(%ecx)
 > 0xc0467cc8 <pmap_activate+76>:  jmp    0xc0467c99 <pmap_activate+29>
 > 0xc0467cca <pmap_activate+78>:  movl   $0x0,0xc0(%ecx)
 > 0xc0467cd4 <pmap_activate+88>:  jmp    0xc0467c99 <pmap_activate+29>
 > 0xc0467cd6 <pmap_activate+90>:  push   $0xc080baa0
 > 0xc0467cdb <pmap_activate+95>:  push   $0x79a
 > 0xc0467ce0 <pmap_activate+100>: push   $0xc080b9c0
 > 0xc0467ce5 <pmap_activate+105>: push   $0xc07952a0
 > 0xc0467cea <pmap_activate+110>: call   0xc0627e38 <__assert>
 > 0xc0467cef <pmap_activate+115>: push   $0xc07aec2a
 > 0xc0467cf4 <pmap_activate+120>: push   $0x799
 > 0xc0467cf9 <pmap_activate+125>: jmp    0xc0467ce0 <pmap_activate+100>
 > 0xc0467cfb <pmap_activate+127>: nop    
 > 0xc0467cfc <pmap_reactivate>:   push   %ebp
 > 0xc0467cfd <pmap_reactivate+1>: mov    %esp,%ebp
 > 0xc0467cff <pmap_reactivate+3>: push   %edi
 > 0xc0467d00 <pmap_reactivate+4>: push   %esi
 > 0xc0467d01 <pmap_reactivate+5>: push   %ebx
 > 
 > 	and 0x39 = 57, so the last instruction above was where the
 > 	problem hit.  This appears to be
 > 
 > 	pcb = &l->l_addr->u_pcb;
 > 
 > 	in pmap_activate() which is the source for these instructions.
 
 I believe it is rather
 	pcb->pcb_ldt_sel = pmap->pm_ldt_sel;
 
 eax == pmap, edx == pcb.
 
 This means that pmap == 0xdeadbeef. Moreover, at this point, pmap should
 be the process' 0 (i.e. kernel's) pmap! (see
 	/*
  	 * borrow proc0's address space.
  	 */
  	pmap_deactivate(l);
  	p->p_vmspace = proc0.p_vmspace;
  	pmap_activate(l);
 
 in uvm_proc_exit)
 
 So either somebody freed the kernel's vmspace, or for some reason
 p->p_vmspace is not the process 0 vmspace.
 
 Could you look if proc0.p_vmspace->vm_map.pmap is 0xdeadbeef at this point?