From owner-freebsd-current@FreeBSD.ORG Tue May 20 14:31:42 2003 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 3747B37B401 for ; Tue, 20 May 2003 14:31:42 -0700 (PDT) Received: from ion.gank.org (ion.gank.org [198.78.66.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D2543F93 for ; Tue, 20 May 2003 14:31:41 -0700 (PDT) (envelope-from craig@xfoil.gank.org) Received: from localhost (ion.gank.org [198.78.66.164]) by ion.gank.org (GankMail) with ESMTP id C9AFD2CFA9 for ; Tue, 20 May 2003 16:31:36 -0500 (CDT) Received: from ion.gank.org ([198.78.66.164]) by localhost (ion.gank.org [198.78.66.164]) (amavisd-new, port 10024) with LMTP id 28551-01-2 for ; Tue, 20 May 2003 16:31:36 -0500 (CDT) Received: from owen1492.uf.corelab.com (pix.corelab.com [12.45.169.2]) by ion.gank.org (GankMail) with ESMTP id 52AB62BBB7 for ; Tue, 20 May 2003 16:31:36 -0500 (CDT) From: Craig Boston To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Organization: Message-Id: <1053466303.815.22.camel@owen1492.uf.corelab.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 May 2003 16:31:44 -0500 Content-Transfer-Encoding: 8bit Subject: Reproducable panic in in6_pcbbind 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: Tue, 20 May 2003 21:31:42 -0000 I can make it happen pretty reliably by connecting and disconnecting an ssh session with dynamic port forwarding (socks4) enabled. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02d34f1 stack pointer = 0x10:0xdd537bec frame pointer = 0x10:0xdd537c34 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 = 34399 (ssh) panic: from debugger (kgdb) where ----SNIP doadump and all the ddb stuff--- #10 0xc03881bd in trap (frame= {tf_fs = 24, tf_es = -1071579120, tf_ds = -1069350896, tf_edi = -1069229312, tf_esi = -992783104, tf_ebp = -581731276, tf_isp = -581731368, tf_ebx = -1002924256, tf_edx = 16, tf_ecx = -969045556, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070779151, tf_cs = 8, tf_eflags = 66054, tf_esp = -1069229312, tf_ss = -968505304}) at /usr/src/sys/i386/i386/trap.c:433 #11 0xc0378458 in calltrap () at {standard input}:96 #12 0xc02bc2ca in tcp6_usr_bind (so=0x0, nam=0xc4389720, td=0xc650a850) at /usr/src/sys/netinet/tcp_usrreq.c:296 #13 0xc02556b3 in sobind (so=0x0, nam=0x0, td=0x0) ---Type to continue, or q to quit--- at /usr/src/sys/kern/uipc_socket.c:228 #14 0xc02595b7 in kern_bind (td=0xc650a850, fd=0, sa=0xc645c820) at /usr/src/sys/kern/uipc_syscalls.c:195 #15 0xc0259523 in bind (td=0x0, uap=0xdd537d10) at /usr/src/sys/kern/uipc_syscalls.c:175 #16 0xc0388c7a in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134632064, tf_esi = 4, tf_ebp = -1077937960, tf_isp = -581730956, tf_ebx = 671804352, tf_edx = 54, tf_ecx = 54, tf_eax = 104, tf_trapno = 0, tf_err = 2, tf_eip = 673312483, tf_cs = 31, tf_eflags = 582, tf_esp = -1077939172, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1021 #17 0xc03784ad in Xint0x80_syscall () at {standard input}:138 ---Can't read userspace from dump, or kernel process--- (kgdb) up 12 #12 0xc02bc2ca in tcp6_usr_bind (so=0x0, nam=0xc4389720, td=0xc650a850) at /usr/src/sys/netinet/tcp_usrreq.c:296 296 error = in6_pcbbind(inp, nam, td); inp, nam, and td all look like valid pointers at this point, though nam is $10 = {sa_len = 0 '\0', sa_family = 0 '\0', sa_data = "\0\0\0\0\0\0<69ÆäÚDÀ"} which looks bogus, though sa_len is checked and it should just return EINVAL with this input. Also, the backtrace looks a bit suspicious... #12 0xc02bc2ca in tcp6_usr_bind (so=0x0, nam=0xc4389720, td=0xc650a850) #13 0xc02556b3 in sobind (so=0x0, nam=0x0, td=0x0) #14 0xc02595b7 in kern_bind (td=0xc650a850, fd=0, sa=0xc645c820) #15 0xc0259523 in bind (td=0x0, uap=0xdd537d10) td=0x0 looks bad, and it seems really weird that nam and td change in the call to tcp6_usr_bind since sobind just calls it with the same arguments it was given. Stack corruption maybe? sobind should have choked on the null pointer long before it ever got to tcp6_usr_bind... Any clues? Thanks, Craig