Subject: kern/21964: kernel traps in in_pcbconnect
To: None <gnats-bugs@gnats.netbsd.org>
From: None <bsd@cs.ubc.ca>
List: netbsd-bugs
Date: 06/22/2003 21:10:38
>Number: 21964
>Category: kern
>Synopsis: kernel traps in in_pcbconnect
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jun 23 04:14:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Brian de Alwis
>Release: NetBSD 1.6U
>Organization:
>Environment:
System: NetBSD slab 1.6U NetBSD 1.6U (SLAB) #3: Fri Jun 20 12:09:38 PDT 2003 bsd@slab:/usr/src/sys/arch/i386/compile/SLAB i386
Architecture: i386
Machine: i386
>Description:
I received the following trap on my laptop running very recent
-current. I don't think I triggered anything, as I was only
doing some editting in vi at the time (the previous message
was from 5 minutes previous):
Jun 22 20:20:37 slab apm: Resuming done.
Jun 22 20:25:03 slab syslogd: restart
Jun 22 20:25:03 slab /netbsd: uvm_fault(0xd3dddb44, 0, 0, 1) -> 0xe
Jun 22 20:25:03 slab /netbsd: fatal page fault in supervisor mode
Jun 22 20:25:03 slab /netbsd: trap type 6 code 0 eip c010a588 cs 8 eflags 10297 cr2 60 ilevel 5
Jun 22 20:25:03 slab /netbsd: panic: trap
Jun 22 20:25:03 slab /netbsd: Begin traceback...
Jun 22 20:25:03 slab /netbsd: trap() at netbsd:trap+0x21a
Jun 22 20:25:03 slab /netbsd: --- trap (number 6) ---
Jun 22 20:25:03 slab /netbsd: in_pcbconnect(c0a72288,c0a09200,10,c026b101,0) at netbsd:in_pcbconnect+0x19c
Jun 22 20:25:03 slab /netbsd: udp_usrreq(c0af60d0,4,0,c0a09200,0) at netbsd:udp_usrreq+0x1a1
Jun 22 20:25:03 slab /netbsd: soconnect(c0af60d0,c0a09200,10,3,d3de5e84) at netbsd:soconnect+0x8d
Jun 22 20:25:03 slab /netbsd: sys_connect(d3de5e84,d3e38f80,d3e38f78,c02de74c,48272300) at netbsd:sys_connect+0x82
Jun 22 20:25:03 slab /netbsd: syscall_plain(1f,1f,1f,1f,8098000) at netbsd:syscall_plain+0xab
Jun 22 20:25:03 slab /netbsd: End traceback...
Jun 22 20:25:03 slab /netbsd: syncing disks... 1 1 1 done
Jun 22 20:25:03 slab /netbsd:
Jun 22 20:25:03 slab /netbsd: dump to dev 0,1 not possible
Jun 22 20:25:03 slab /netbsd: rebooting...
Following the stack trace, and some objdump, in_pcbconnect
starts at 0x59c, and so 0x19c in is address 0x738, which
correlates to this section, using objdump:
726: 83 c4 10 add $0x10,%esp
729: 83 f8 23 cmp $0x23,%eax
72c: 75 0a jne 738 <in_pcbconnect+0x19c>
72e: b8 23 00 00 00 mov $0x23,%eax
733: eb 77 jmp 7ac <in_pcbconnect+0x210>
735: 8d 76 00 lea 0x0(%esi),%esi
738: 8b 43 60 mov 0x60(%ebx),%eax
73b: 89 46 44 mov %eax,0x44(%esi)
73e: 89 5e 68 mov %ebx,0x68(%esi)
741: 8b 83 94 00 00 00 mov 0x94(%ebx),%eax
This seems to be in the following lines from in_pcbconnect (from
net/in_pcb.c, $NetBSD: in_pcb.c,v 1.82 2003/06/15 02:49:33 matt Exp $):
if (error == EAGAIN)
return (error);
}
KASSERT(inp->inp_ia == NULL);
inp->inp_laddr = ia->ia_addr.sin_addr; /** LINE 439 **/
inp->inp_ia = ia;
LIST_INSERT_HEAD(&ia->ia_inpcbs, inp, inp_ialink);
From the assembly, my guess is it corresponds to the load
of `ia->ia_addr.sin_addr' in the line 439; I'm supposing
I don't have KASSERT defined. From looking above, I'd
guess in my circumstance, this code never enters the foreach
loop 389, and somehow skips the situation at line 419 such
that <ia> is NULL.
As to my situation: my laptop has a builtin ethernet (an
3Com 3c905C-TX 10/100). I had this configured to a local
network in my home, but had powered off the small hub, so
the machine was effectively standalone.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: