Re: crash on 4.2-stable (sendto() system call)

2000-11-28 Thread FengYue


On Thu, 23 Nov 2000, FengYue wrote:

-dmesg: kvm_read: 

-#6  0xc01882dd in fr_makefrip (hlen=20, ip=0xc0a48fe4, fin=0xd892fb0c)
-at ../../netinet/fil.c:258
-#7  0xc018e20c in fr_checkicmpmatchingstate (ip=0xc0a48fc8,
-fin=0xd892fc1c)
-at ../../netinet/ip_state.c:1081

Hi, I'm looking at ip_state.c and fr_makefrip.c, there is one thing
I don't quiet understand and see if any of you could explain a bit to me:

in ip_state.c:973, it declares fr_info_t ofin on the function stack --
apearly uninit'ed, then at line 1081 it calls
fr_makefrip(...,...,ofin); (ofin is not init'ed in anyway before calling
fr_makefrip() at line 1081)

in fil.c:202, fr_makefrip(), it does some assignments to elements in *fin
which points to ofin in ip_state.c:1081, anyway, fin is not init'ed and
later in fr_makefrip():227 it checks for fin-fin_v which contains the
IP version, obviously I think fin-fin_v is some garbage at this point
and if it happened to have value '6' in fin_v, then V6 code will be
executed and thus would cause a panic at line fil.c:258 just like what
shows in  the GDB trace.

Did I find the bug causing the panic or did I miss something?

As I mentioned in my previous E-mail, a machine of mine crashed 10 hours
after upgrading to 4.2-stable.  After the crash I commented out an
IPFW ruleset which basically allows icmp type 0  11 to be in, until
now the machine has not experienced a panic. 

Thanks




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: crash on 4.2-stable (sendto() system call)

2000-11-28 Thread FengYue


On Tue, 28 Nov 2000, FengYue wrote:
-Did I find the bug causing the panic or did I miss something?

Also, if it's the bug that causes the panic, the fix should be
pretty simple i guess, like do something like this before the IP
version check:

fin_fin_v = ip-ip_v;

right?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: crash on 4.2-stable (sendto() system call)

2000-11-23 Thread Bosko Milekic


  Hello,

Can you please also get the instruction at which the page fault
  occured? You can try "where" from gdb or you can get the instruction
  pointer from the original page fault message and then you can probably
  "disassemble fr_makefrip" and get us the contents around the instruction
  generating the fault.


On Thu, 23 Nov 2000, FengYue wrote:

 
 Hi, got a crash on 4.2-stable. the machine was running 4.1.1-stable
 and had no problem at all.  10 hours after upgrade to 4.2-stable I got
 a vmcore.   Here it's the trace and could someone take a look, it looks
 like it was the sendto() call triggered the crash but I don't know
 how to reproduce it.
 
 Thanks
 
 ---
 initial pcb at 24c320
 panicstr: page fault
 panic messages:
 ---
 dmesg: kvm_read: 
 ---
 #0  0xc013336e in dumpsys ()
 (kgdb) bt
 #0  0xc013336e in dumpsys ()
 #1  0xc013318f in boot ()
 #2  0xc013350c in poweroff_wait ()
 #3  0xc0200461 in trap_fatal ()
 #4  0xc0200139 in trap_pfault ()
 #5  0xc01ffd1f in trap ()
 #6  0xc01882dd in fr_makefrip ()
 #7  0xc018e20c in fr_checkicmpmatchingstate ()
 #8  0xc018e44d in fr_checkstate ()
 #9  0xc0188ecc in fr_check ()
 #10 0xc017d124 in ip_output ()
 #11 0xc017b416 in icmp_send ()
 #12 0xc017b397 in icmp_reflect ()
 #13 0xc017acbd in icmp_error ()
 #14 0xc0185be4 in udp_input ()
 #15 0xc017bdcb in ip_input ()
 #16 0xc017be2b in ipintr ()
 #17 0xc01f69d5 in swi_net_next ()
 #18 0xc0153881 in sendit ()
 #19 0xc0153975 in sendto ()
 #20 0xc020070d in syscall2 ()
 #21 0xc01f5575 in Xint0x80_syscall ()
 Cannot access memory at address 0xbfbffc8c.
 

  Regards,
  Bosko Milekic
  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: crash on 4.2-stable (sendto() system call)

2000-11-23 Thread Alfred Perlstein

* Bosko Milekic [EMAIL PROTECTED] [001123 14:51] wrote:
 
   Hello,
 
   Can you please also get the instruction at which the page fault
   occured? You can try "where" from gdb or you can get the instruction
   pointer from the original page fault message and then you can probably
   "disassemble fr_makefrip" and get us the contents around the instruction
   generating the fault.

It would be better if he could add '-g' to his makeoptions and
get a crashdump with debug symbols.

-Alfred


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: crash on 4.2-stable (sendto() system call)

2000-11-23 Thread FengYue


On Thu, 23 Nov 2000, Alfred Perlstein wrote:

-* Bosko Milekic [EMAIL PROTECTED] [001123 14:51] wrote:
- 
-   Hello,
- 
- Can you please also get the instruction at which the page fault
-   occured? You can try "where" from gdb or you can get the instruction
-   pointer from the original page fault message and then you can probably
-   "disassemble fr_makefrip" and get us the contents around the instruction
-   generating the fault.
-
-It would be better if he could add '-g' to his makeoptions and
-get a crashdump with debug symbols.
-
--Alfred
-

Ah, yes, I actually have -g option turned on.  Forgot to do a gdb -k on
the kernel.debug instead.  Ok, here comes the new trace:

--

shell# gdb -k kernel.debug /var/crash/vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2883584
initial pcb at 24c320
panicstr: page fault
panic messages:
---
dmesg: kvm_read: 
---
#0  dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0  dumpsys () at ../../kern/kern_shutdown.c:469
#1  0xc013318f in boot (howto=256) at ../../kern/kern_shutdown.c:309
#2  0xc013350c in poweroff_wait (junk=0xc022952f, howto=-662374720)
at ../../kern/kern_shutdown.c:556
#3  0xc0200461 in trap_fatal (frame=0xd892fa68, eva=3232010240)
at ../../i386/i386/trap.c:951
#4  0xc0200139 in trap_pfault (frame=0xd892fa68, usermode=0,
eva=3232010240)
at ../../i386/i386/trap.c:844
#5  0xc01ffd1f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
  tf_edi = -1062957084, tf_esi = 0, tf_ebp = -661456160, 
  tf_isp = -661456236, tf_ebx = 0, tf_edx = -661456112, 
  tf_ecx = -661456116, tf_eax = 11008, tf_trapno = 12, tf_err = 0, 
  tf_eip = -1072135459, tf_cs = 8, tf_eflags = 66118, tf_esp = 16128, 
  tf_ss = 638}) at ../../i386/i386/trap.c:443
#6  0xc01882dd in fr_makefrip (hlen=20, ip=0xc0a48fe4, fin=0xd892fb0c)
at ../../netinet/fil.c:258
#7  0xc018e20c in fr_checkicmpmatchingstate (ip=0xc0a48fc8,
fin=0xd892fc1c)
at ../../netinet/ip_state.c:1081
#8  0xc018e44d in fr_checkstate (ip=0xc0a48fc8, fin=0xd892fc1c)
at ../../netinet/ip_state.c:1194
#9  0xc0188ecc in fr_check (ip=0xc0a48fc8, hlen=20, ifp=0xc02634e0, out=1, 
mp=0xd892fcd4) at ../../netinet/fil.c:887
#10 0xc017d124 in ip_output (m0=0xc0a48f00, opt=0x0, ro=0xd892fd14,
flags=0, 
---Type return to continue, or q return to quit---
imo=0x0) at ../../netinet/ip_output.c:437
#11 0xc017b416 in icmp_send (m=0xc0a48f00, opts=0x0)
at ../../netinet/ip_icmp.c:753
#12 0xc017b397 in icmp_reflect (m=0xc0a48f00) at
../../netinet/ip_icmp.c:715
#13 0xc017acbd in icmp_error (n=0xc099e900, type=3, code=3, dest=0, 
destifp=0x0) at ../../netinet/ip_icmp.c:225
#14 0xc0185be4 in udp_input (m=0xc099e900, off=20, proto=17)
at ../../netinet/udp_usrreq.c:364
#15 0xc017bdcb in ip_input (m=0xc099e900) at ../../netinet/ip_input.c:731
#16 0xc017be2b in ipintr () at ../../netinet/ip_input.c:759
#17 0xc01f69d5 in swi_net_next ()
#18 0xc0153881 in sendit (p=0xd884f6c0, s=4, mp=0xd892ff10, flags=0)
at ../../kern/uipc_syscalls.c:520
#19 0xc0153975 in sendto (p=0xd884f6c0, uap=0xd892ff80)
at ../../kern/uipc_syscalls.c:572
#20 0xc020070d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = 134594596, tf_esi = 4, tf_ebp = -1077937012, 
  tf_isp = -661454892, tf_ebx = 134569988, tf_edx = 134594560, 
  tf_ecx = -37, tf_eax = 133, tf_trapno = 12, tf_err = 2, 
  tf_eip = 671903036, tf_cs = 31, tf_eflags = 514, tf_esp =
-1077937104, 
  tf_ss = 47}) at ../../i386/i386/trap.c:1150
#21 0xc01f5575 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbffc8c.
(kgdb) disassemble fr_makefrip
Dump of assembler code for function fr_makefrip:
0xc0188174 fr_makefrip:   push   %ebp
0xc0188175 fr_makefrip+1: mov%esp,%ebp
0xc0188177 fr_makefrip+3: sub$0x2c,%esp
0xc018817a fr_makefrip+6: push   %edi
0xc018817b fr_makefrip+7: push   %esi
0xc018817c fr_makefrip+8: push   %ebx
0xc018817d fr_makefrip+9: mov0xc(%ebp),%edi
0xc0188180 fr_makefrip+12:mov0x10(%ebp),%ecx
0xc0188183 fr_makefrip+15:movw   $0x0,0xfffe(%ebp)
0xc0188189 fr_makefrip+21:movw   $0x0,0xfffc(%ebp)
0xc018818f fr_makefrip+27:movw   $0x0,0xfff8(%ebp)
0xc0188195 fr_makefrip+33:lea0x4(%ecx),%eax
0xc0188198 fr_makefrip+36:mov%eax,0xffec(%ebp)
0xc018819b fr_makefrip+39:movb   $0x0,0x35(%ecx)
0xc018819f fr_makefrip+43:movl   $0x0,0x40(%ecx)
0xc01881a6 fr_makefrip+50:movb   $0x0,0x38(%ecx)
0xc01881aa fr_makefrip+54:movw   $0x0,0x30(%ecx)
0xc01881b0