Bug #267
closed
pf crash + questions
0%
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
Updated by corecode over 18 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
- asf -s /modules
[paste output]
^D - fg
(kgdb) source .asf
(kgdb) bt
cheers
simon
Updated by rnyberg over 18 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
- asf -s /modules
[paste output]
^D- 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
Updated by rnyberg over 18 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