Bug #267

pf crash + questions

Added by rnyberg over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue 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

History

#1 Updated by corecode over 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

#2 Updated by rnyberg over 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

#3 Updated by rnyberg over 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

#4 Updated by corecode over 7 years ago

duplicate

Also available in: Atom PDF