=================================================================== RCS file: /cvsrepo/anoncvs/cvs/www/ddb.html,v retrieving revision 1.20 retrieving revision 1.21 diff -c -r1.20 -r1.21 *** www/ddb.html 2018/09/05 14:27:12 1.20 --- www/ddb.html 2019/05/27 22:55:19 1.21 *************** *** 1,30 **** ! ! ! OpenBSD: Crash Reports - - ! - ! ! !

! OpenBSD ! Crash Reports


-

Minimum information for kernel problems

Familiarize yourself with the general bug reporting procedures first. --- 1,29 ---- ! ! ! ! OpenBSD: Crash Reports ! !

! OpenBSD ! Crash Reports

+

Minimum information for kernel problems

+

Familiarize yourself with the general bug reporting procedures first. *************** *** 32,63 **** When reporting a kernel panic or crash, please remember:

! Reports without the above information are useless. This is the minimum we need to be able to track down the issue. !

Additional information you can send

In some situations more information is desirable. Below are outlined some additional steps you can take in certain situations: --- 31,64 ---- When reporting a kernel panic or crash, please remember: !

! Reports without the above information are useless. This is the minimum we need to be able to track down the issue. !

Additional information you can send

+

In some situations more information is desirable. Below are outlined some additional steps you can take in certain situations: *************** *** 66,77 **** The following additional things would be helpful

  • ... XXX boot crash? XXX --- 67,78 ---- The following additional things would be helpful
  • ... XXX boot crash? XXX *************** *** 80,85 **** --- 81,87 ----

    Lost the panic message?

    +

    Under some circumstances, you may lose the very first message of a panic, stating the reason for the panic. *************** *** 91,96 **** --- 93,99 ----

    Note for SMP systems

    +

    You should get a trace from each processor as part of your report:

    ***************
    *** 117,127 ****
      ddb{1}>
      
    ! Repeat the machine ddbcpu x followed by trace for each processor in your machine.

    How do I gather further information from a kernel crash?

    A typical kernel crash on OpenBSD might look like this:

    --- 120,132 ----
      ddb{1}>
      
    !

    ! Repeat the machine ddbcpu x followed by trace for each processor in your machine.

    How do I gather further information from a kernel crash?

    +

    A typical kernel crash on OpenBSD might look like this:

    ***************
    *** 130,140 ****
      ddb>
      
    ! This crash happened at offset 0x263 in the function pf_route.

    The first command to run from the ! ddb(4) prompt is trace:

      ddb> trace
    --- 135,146 ----
      ddb>
      
    !

    ! This crash happened at offset 0x263 in the function pf_route.

    The first command to run from the ! ddb(4) prompt is trace:

      ddb> trace
    ***************
    *** 152,157 ****
    --- 158,164 ----
      ddb>
      
    +

    This tells us what function calls lead to the crash.

    *************** *** 160,191 ****

    Find the source file where the crashing function is defined. ! In this example, that would be pf_route() in /sys/net/pf.c. Use objdump(1) to get the disassembly:

      $ cd /sys/arch/$(uname -m)/compile/GENERIC
    ! $ objdump -dlr obj/pf.o >/tmp/pf.dis
      
    In the output, grep for the function name:
    ! $ grep "<pf_route>:" /tmp/pf.dis
    ! 00007d88 <pf_route>:
      
    ! Take this first hex number 7d88 and add the offset 0x263 from ! the Stopped at line:
      $ printf '%x\n' $((0x7d88 + 0x263))
      7feb
      
    ! Scroll down to the line 7feb. ! The assembler instruction should match the one quoted in the Stopped at line. Then scroll up to the nearest C line number: --- 167,201 ----

    Find the source file where the crashing function is defined. ! In this example, that would be pf_route() in /sys/net/pf.c. Use objdump(1) to get the disassembly:

      $ cd /sys/arch/$(uname -m)/compile/GENERIC
    ! $ objdump -dlr obj/pf.o >/tmp/pf.dis
      
    +

    In the output, grep for the function name:

    ! $ grep "<pf_route>:" /tmp/pf.dis
    ! 00007d88 <pf_route>:
      
    !

    ! Take this first hex number 7d88 and add the offset 0x263 from ! the Stopped at line:

      $ printf '%x\n' $((0x7d88 + 0x263))
      7feb
      
    !

    ! Scroll down to the line 7feb. ! The assembler instruction should match the one quoted in the Stopped at line. Then scroll up to the nearest C line number: *************** *** 195,217 **** 7fe7: 0f b7 43 02 movzwl 0x2(%ebx),%eax 7feb: 8b 57 40 mov 0x40(%edi),%edx 7fee: 39 d0 cmp %edx,%eax ! 7ff0: 0f 87 92 00 00 00 ja 8088 <pf_route+0x300> ! So, it's precisely line 3872 of pf.c that crashes:

      $ nl -ba /sys/net/pf.c | sed -n 3872p
    !   3872		if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
      
    The kernel that produced the crash output and the object file for objdump must be compiled from the exact same source file, otherwise the offsets won't match.

    If you provide both the ddb trace output and the relevant objdump section, that's very helpful. - -

    - - --- 205,225 ---- 7fe7: 0f b7 43 02 movzwl 0x2(%ebx),%eax 7feb: 8b 57 40 mov 0x40(%edi),%edx 7fee: 39 d0 cmp %edx,%eax ! 7ff0: 0f 87 92 00 00 00 ja 8088 <pf_route+0x300> !

    ! So, it's precisely line 3872 of pf.c that crashes:

      $ nl -ba /sys/net/pf.c | sed -n 3872p
    !   3872		if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
      
    +

    The kernel that produced the crash output and the object file for objdump must be compiled from the exact same source file, otherwise the offsets won't match.

    If you provide both the ddb trace output and the relevant objdump section, that's very helpful.