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 <return> to continue, or q <return> 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, CraigReceived on Tue May 20 2003 - 12:31:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:08 UTC