Date: Thu, 12 Aug 2004 19:22:59 +0200 From: Andre Oppermann <andre@freebsd.org> To: Don Lewis <truckman@FreeBSD.org> Cc: rwatson@FreeBSD.org Subject: Re: SCHEDULE and high load situations Message-ID: <411BA773.4090204@freebsd.org> In-Reply-To: <200408121709.i7CH98H8020875@gw.catspoiler.org> References: <200408121709.i7CH98H8020875@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?411BA773.4090204>