Bug #267
pf crash + questions
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
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
Related todos
History
Updated by corecode almost 7 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 almost 7 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 almost 7 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
Updated by corecode over 6 years ago
duplicate