On Sat, Aug 01, 2015 at 08:46:00PM +0200, Mike Belopuhov wrote: > On 1 August 2015 at 19:20, RD Thrush <openbsd-t...@thrush.com> wrote: > > > > The patch ran without panic for 20+ hours. > > > > Thanks for testing! > > > I wondered about the removal of the panic() statement so I tried > > another kernel that added the memset() but kept the panic() statement, as > > follows: > > > [snip] > > > > That kernel panic'd as before with "no appropriate pool". > > Well of course. Not all rules are rdr/nat/route-to. > > > Was the Jul 20 cvs commit (panic addition) incorrect? > > It has served it's purpose well: it has found this bug. > But panic'ing here in general is of course incorrect. > > > If not, it appears the memset() addition didn't fix the panic. > > > > It did, clearly. You can run your setup again (-: > > > I was able to take a crash dump with the above change and have > > attached a gdb transcript. The stack is apparently damaged in the > > pf_postprocess_addr() function; however, I'm over my head at this > > point. How may I help further troubleshoot? > > You're slightly overanalyzing here: panic has caught the unhandled > case, but it's not needed per se. >
The code directly after the panic assumes rpool is set. Something is clearly wrong in the pf code if this triggers. Without a pf.conf it is hard to guess as to why this triggers...
