tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sysctl_net_inet_tcp_ident panic



In article <Pine.NEB.4.64.1310032322420.15246%andromeda.ziaspace.com@localhost>,
John Klos  <john%ziaspace.com@localhost> wrote:
>Hi,
>
>I have an amd64 system running netbsd-6 from 2-September-2013. Today, 
>while a few machines were scp'ing, this happened:
>
>
>uvm_fault(0xfffffe80c01971d0, 0x0, 1) -> e
>fatal page fault in supervisor mode
>trap type 6 code 0 rip ffffffff804a9fbf cs 8 rflags 10246 cr2  44 cpl 0 
>rsp ffff8001229c8960
>panic: trap
>cpu2: Begin traceback...
>printf_nolog() at netbsd:printf_nolog
>startlwp() at netbsd:startlwp
>alltraps() at netbsd:alltraps+0x96
>sysctl_net_inet_tcp_ident() at netbsd:sysctl_net_inet_tcp_ident+0x3ee
>sysctl_dispatch() at netbsd:sysctl_dispatch+0xb2
>sys___sysctl() at netbsd:sys___sysctl+0xeb
>syscall() at netbsd:syscall+0xc4
>cpu2: End traceback...
>
>dumping to dev 0,1 offset 212671
>dump succeeded

Looks like a NULL pointer dereference. using objdump you can find
the instruction sequence in the file. Then you can compile the source
file with -gstabs -S and get an assembly file that has the line
numbers with the code. At this point you should be able to see the
line number that caused the fault. Also set ddb.onpanic=2 and run
a ps to see what process ran the sysctl. Of course if the crash
worked, you can figure the same by running gdb on the core file.

christos



Home | Main Index | Thread Index | Old Index