From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:23:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 466E816A4CE for ; Thu, 12 Aug 2004 17:23:02 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 852DB43D2F for ; Thu, 12 Aug 2004 17:23:01 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 205 invoked from network); 12 Aug 2004 17:16:46 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 17:16:46 -0000 Message-ID: <411BA773.4090204@freebsd.org> Date: Thu, 12 Aug 2004 19:22:59 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Lewis References: <200408121709.i7CH98H8020875@gw.catspoiler.org> In-Reply-To: <200408121709.i7CH98H8020875@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: mb@imp.ch cc: rwatson@FreeBSD.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 17:23:02 -0000 Don Lewis wrote: > On 12 Aug, Martin Blapp wrote: >> >>Here is more information: (thanks robert for the help) >> >>>Fatal trap 12: page fault while in kernel mode >>>cpuid = 1; apic id = 01 >>>fault virtual address = 0x14 >>>fault code = supervisor write, page not present >>>instruction pointer = 0x8:0xc066a1c7 >>>stack pointer = 0x10:0xe2626aa8 >>>frame pointer = 0x10:0xe2626ab8 >>>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 = 27897 (mimedefang) >>> >> >>db> where >>unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892 >>unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865 >>uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179 >>soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518 >>kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477 >>connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 >>syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 >>Xint0x80_syscall() at Xint0x80_syscall+0x1f >>--- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- >> >>src/sys/kern/uipc_syscalls.c,v 1.199 >>src/sys/kern/uipc_usrreq.c,v 1.135 >>src/sys/kern/uipc_socket.c,v 1.207 >> >>(gdb) l *unp_connect2+0x2a >>0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). >>887 UNP_LOCK_ASSERT(); >>888 >>889 if (so2->so_type != so->so_type) >>890 return (EPROTOTYPE); >>891 unp2 = sotounpcb(so2); >>892 unp->unp_conn = unp2; >>893 switch (so->so_type) { >>894 >>895 case SOCK_DGRAM: >>896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); > > > Looks like unp is NULL here. > > My first suspicion would be the recent memory allocation changes that > affected the type safety of various dynamically allocated data > structures, though I'm not sure that fits the symptoms. I have backed out the change this morning (GMT) because of concernes of this. It looks like the code accesses free'd memory or uninitialized memory. This might have worked in the SPL days but today with SMP it's tough. You never know if the free'd memory has been allocated again already somewhere else even if it is type-stable. -- Andre