[RPZ] 9.9.3-rpz2+rl.150.20 fails to launch "due to assertion failure"

[Vernon Schryver]

> From: darx+dnsrpz at sent.com

> I've built bind with the latest RPZ+RL patches
>
>   BIND 9.9.3-rpz2+rl.150.20
>
> no issues on the build, but at launch, using the same config that
> successfully launches with 9.9.2-P2+patches, it fails with "exiting (due
> to assertion failure)",

> -->     2013-05-30T17:32:34.487118-07:00 core named[16118]:
> parser.c:2432: REQUIRE(prev > 0) failed

> where

> 		cfg_obj_destroy(cfg_parser_t *pctx, cfg_obj_t **objp) {
> 		    cfg_obj_t *obj;
> 2432        unsigned int refs;
>
> 		    REQUIRE(objp != NULL && *objp != NULL);
> 		    REQUIRE(pctx != NULL);
> 		...

Can you share the response-policy{} and rate-limit{} statements from
the named.conf (or whatever) file?

The nearest plausible "REQUIRE(prev > 0)" is 7 lines later inside the
isc_refcount_decrement() macro at line 2439.
That line number difference is surprising.
Assertions must not be turned off, because it is a REQUIRE() macro
that is assert-botching.
I would not expect the compiler's optimization to move be able to move
the REQUIRE(prev>0) check above the checks on objp and pctx and the
locking inside isc_refcount_decrement().
In other words, could the `named` program that tried to start be other
than the the patched version?  Does `named -V` say something like
"9.9.3-rpz2+rl.150.20"?

What does are the ./configure options disclosed by `named -V`?

Is there a stack trace in a named.run file somewhere?  By adding the 
bogus assertion "REQUIRE(objp == NULL);" before line 2437, I got
these lines in named.run:

    31-May-2013 01:28:33.032 parser.c:2437: REQUIRE(objp == ((void *)0)) failed, bac
    k trace
    31-May-2013 01:28:33.032 #0 0x41934f in assertion_failed()+0x5f
    31-May-2013 01:28:33.032 #1 0x60fd2d in isc_assertion_failed()+0x2d
    31-May-2013 01:28:33.032 #2 0x60b67c in cfg_obj_destroy()+0x7c
    31-May-2013 01:28:33.032 #3 0x43c8e2 in load_configuration()+0x29e2
    31-May-2013 01:28:33.032 #4 0x43d469 in run_server()+0x259
    31-May-2013 01:28:33.032 #5 0x635f42 in dispatch()+0x352
    31-May-2013 01:28:33.032 #6 0x63653d in run()+0x1d
    31-May-2013 01:28:33.032 #7 0x801d9d274 in _fini()+0x80174e7c0
    31-May-2013 01:28:33.032 #8 0x0 in ??
    31-May-2013 01:28:33.032 exiting (due to assertion failure)

ISC has instructions on how to get and submit core files at
https://kb.isc.org/article/AA-00340/0/What-to-do-if-your-BIND-or-DHCP-server-has-crashed.html


thanks,
Vernon Schryver    vjs at rhyolite.com