Re: SCHEDULE and high load situations

From: Don Lewis <truckman_at_FreeBSD.org>
Date: Thu, 12 Aug 2004 10:09:08 -0700 (PDT)
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.
Received on Thu Aug 12 2004 - 15:09:16 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:05 UTC