From owner-freebsd-hackers Sun Jun 9 22:32:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A419A37B404 for ; Sun, 9 Jun 2002 22:32:40 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5A5V8V7000451; Mon, 10 Jun 2002 07:31:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Arun Sharma Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 0xdeadxxxx ? In-Reply-To: Your message of "Sun, 09 Jun 2002 17:23:16 PDT." <20020610002316.GA6628@sharma-home.net> Date: Mon, 10 Jun 2002 07:31:08 +0200 Message-ID: <450.1023687068@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020610002316.GA6628@sharma-home.net>, Arun Sharma writes: >I just got a kernel mode page fault. I'd like to find out more >about > >> fault virtual address = 0xdeadc162 0xdeadcode is used to fill freed memory. > >It looks like the address is meant to signal a particular class of >error. Which one ? > > -Arun > >Background fsck: > >Fatal trap 12: page fault while in kernel mode >cpuid = 0; lapic.id = 00000000 >fault virtual address = 0xdeadc162 >fault code = supervisor read, page not present >instruction pointer = 0x8:0xc0277ebe >stack pointer = 0x10:0xcaee688c >frame pointer = 0x10:0xcaee68b0 >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = interrupt enabled, resume, IOPL = 0 >current process = 343 (cron) >kernel: type 12 trap, code=0 >Stopped at ufs_strategy+0xbc: calll *0(%edx,%eax,4) >db> trace >ufs_strategy(caee68e4,caee6900,c01e7a1a,caee68e4,0) at ufs_strategy+0xbc >ufs_vnoperate(caee68e4) at ufs_vnoperate+0x13 >breadn(cacdbb00,0,0,400,0) at breadn+0xc4 >bread(cacdbb00,0,0,400,0) at bread+0x20 >ffs_blkatoff(cacdbb00,0,0,0,caee69c8) at ffs_blkatoff+0x88 >ufs_lookup(caee6af0,caee6b2c,c01ebe61,caee6af0,caaca274) at >ufs_lookup+0x31f >ufs_vnoperate(caee6af0) at ufs_vnoperate+0x13 >vfs_cache_lookup(caee6b94,caee6bc0,c01efc94,caee6b94,caeb841c) at >vfs_cache_loo9 >ufs_vnoperate(caee6b94) at ufs_vnoperate+0x13 >lookup(caee6c30,caeb841c,caee6bec,c01ce890,c0364178) at lookup+0x2b2 >namei(caee6c30) at namei+0x1df >lstat(caeb841c,caee6d14,2,2,292) at lstat+0x4a >syscall(2f,2f,2f,0,0) at syscall+0x1db >syscall_with_err_pushed() at syscall_with_err_pushed+0x1b >--- syscall (190, FreeBSD ELF, lstat), eip = 0x280b2f33, esp = 0xbfbff1ec, ebp - > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message