Project

General

Profile

Actions

Bug #267

closed

pf crash + questions

Added by rnyberg over 15 years ago. Updated about 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

My dragonfy firewall panics now and then. Using bittorrent greatly enhances
the chances of a panic. Unfortunately the backtraces from the core dumps have
mostly looked like garbage.

Today I enabled DDB on panic and I've had two virtually identical crashes.
The kernel is GENERIC from 1.6.0. Below is the fault and trace (typo warning:
it was copied by hand).

I still have the core dumps if they're needed.

--------------------------
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x383d185e
fault code = supervisor read, page not present
ip = 0x8:0xd53cca40
sp = 0x10:0xd53cca2c
fp = 0x10:0xd53cca50

stopped at 0xd53cca40: idivb 0x6399431e(%eax),%al

db> trace
_end(d53ccc2c, 8716c678, 0, 0) at 0xd53cca40
pf_test_state_tcp(d53ccbf4, 1, d6c46300, d833b200, 14) at pf_test_state_tcp + 0x945
pf_test(1, ccef90b8, d53cccd8, c17048c0, 1) at pf_test + 0x333
pf_check_in(0, d53cccd8, cc3f90b8, 1, d833b200) at pf_check_in + 0x26
pfil_run_hooks(c05f2f20, d53ccd70, ccef90b8, 1, 3040b652) at pfil_run_hooks + 0x59
ip_input(d833b200, d53ccd84, c0357f61, d833b214, 0) at ip_input + 0x2a8
ip_input_handler(d833b214, 0, 0, c02c02220, 0) at ip_input_handler + 0x14
tcpmsg_service_loop(0, 0, 0, 0, 0) at tcpmsg_service_loop + 0xe
lwkt_exit() at lwkt_exit
---------------------------------------

Some questions
1) Is the correct way to generate a core dump from DDB to "call dumpsys"?

2)
The output from "call dumpsys" ended something like this:
....8 7 6 5 4 3 2 1 0 error2 0
succeded!
0xa

What does error2 mean?

3) How do I produce the trace above from kgdb? I'd prefer not having to
copy it by hand :)

Happy hacking!
-Richard

Actions #1

Updated by corecode over 15 years ago

Richard Nyberg wrote:

My dragonfy firewall panics now and then. Using bittorrent greatly enhances
the chances of a panic. Unfortunately the backtraces from the core dumps have
mostly looked like garbage.

duh. so the bug still exists :/ we thought it was fixed, but something still destroys the state tables...

Some questions
1) Is the correct way to generate a core dump from DDB to "call dumpsys"?

or enter "panic". it should dump as well.

3) How do I produce the trace above from kgdb? I'd prefer not having to
copy it by hand :)

kgdb kernel core
[..]
(kgdb) bt

(or, if it occured in a module, you have to load the kmods as well:)

(kgdb) source /usr/src/test/debug/gdb.kernel
(kgdb) kldstat
[mark output]
(kgdb) ^Z
  1. asf -s /modules
    [paste output]
    ^D
  2. fg
    (kgdb) source .asf
    (kgdb) bt

cheers
simon

Actions #2

Updated by rnyberg over 15 years ago

At Sat, 29 Jul 2006 19:26:42 +0200,
Simon 'corecode' Schubert wrote:

Richard Nyberg wrote:

My dragonfy firewall panics now and then. Using bittorrent greatly enhances
the chances of a panic. Unfortunately the backtraces from the core dumps have
mostly looked like garbage.

duh. so the bug still exists :/ we thought it was fixed, but something still destroys the state tables...

Some questions
1) Is the correct way to generate a core dump from DDB to "call dumpsys"?

or enter "panic". it should dump as well.

3) How do I produce the trace above from kgdb? I'd prefer not having to
copy it by hand :)

kgdb kernel core
[..]
(kgdb) bt

(or, if it occured in a module, you have to load the kmods as well:)

(kgdb) source /usr/src/test/debug/gdb.kernel
(kgdb) kldstat
[mark output]
(kgdb) ^Z
  1. asf -s /modules
    [paste output]
    ^D
  2. fg
    (kgdb) source .asf
    (kgdb) bt

Ah! The core dumps weren't garbage, they are much more understandable with
the module symbols loaded. :)

Thanks for the info Simon!

-Richard
Actions #3

Updated by rnyberg over 15 years ago

At Sat, 29 Jul 2006 19:26:42 +0200,
Simon 'corecode' Schubert wrote:

Richard Nyberg wrote:

My dragonfy firewall panics now and then. Using bittorrent greatly
enhances the chances of a panic. Unfortunately the backtraces from
the core dumps have mostly looked like garbage.

duh. so the bug still exists :/ we thought it was fixed, but
something still destroys the state tables...

Is there anything I can do to help debug this problem? Do you want the
cores?

-Richard
Actions #4

Updated by corecode about 15 years ago

duplicate

Actions

Also available in: Atom PDF