BIND 10 #2420: allow loading zones containing an orphan RRSIG

[BIND 10 Development]

#2420: allow loading zones containing an orphan RRSIG
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20121204
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  data   |           Sub-Project:  DNS
  source                             |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  0
            Defect Severity:  High   |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:9 jinmei]:
 > Replying to [comment:8 vorner]:
 >
 > > The size was actually quite OK (the changes were related to each
 other). I just want to confirm, the incoming RRsets need to be (still)
 grouped by the name, right?
 > >
 > > There's one serious thing. The tests don't pass:
 > > {{{
 > > [ RUN      ] ZoneDataUpdaterTest.rrisgForNSEC3Only
 > > unknown file: Failure
 > > C++ exception with description "Unknown NSEC3 algorithm: 200" thrown
 in the test body.
 > > [  FAILED  ] ZoneDataUpdaterTest.rrisgForNSEC3Only (0 ms)
 > > }}}
 >
 > One quick check: I can't reproduce it on my environment.  Is this
 > specific to some special cases like distcheck?  Or does that happen
 > even if you run it on the tests/memory directory by "./run_unittests"?
 > Is it possible that your environment uses the wrong version of shlib?

 It happens every time. However, the reported number of algorithm differs
 from run to run.

 Also, when run with `GTEST_FILTER` to run only the one test, it segfaults.
 Here's a stacktrace, if it is of any help:
 {{{
 Program received signal SIGSEGV, Segmentation fault.
 0x000000000049dbf8 in isc::datasrc::memory::NSEC3Data::getSaltLen
 (this=0x10076ff3f) at
 ../../../../../src/lib/datasrc/memory/zone_data.h:161
 1619    size_t getSaltLen() const { return (*getSaltBuf()); }
 (gdb) bt
 #0  0x000000000049dbf8 in isc::datasrc::memory::NSEC3Data::getSaltLen
 (this=0x10076ff3f) at
 ../../../../../src/lib/datasrc/memory/zone_data.h:161
 #1  0x00007ffff7b8a1da in
 isc::datasrc::memory::ZoneDataUpdater::getNSEC3Hash (this=0x76fc20) at
 zone_data_updater.cc:220
 #2  0x00007ffff7b8b79a in
 isc::datasrc::memory::ZoneDataUpdater::setupNSEC3<isc::dns::rdata::generic::NSEC3>
 (this=0x76fc20, rrset=...)
     at zone_data_updater.cc:240
 #3  0x00007ffff7b8a296 in isc::datasrc::memory::ZoneDataUpdater::addNSEC3
 (this=0x76fc20, name=..., rrset=..., rrsig=...) at
 zone_data_updater.cc:254
 #4  0x00007ffff7b8a597 in
 isc::datasrc::memory::ZoneDataUpdater::addRdataSet (this=0x76fc20,
 name=..., rrtype=..., rrset=..., rrsig=...)
     at zone_data_updater.cc:286
 #5  0x00007ffff7b8aea1 in isc::datasrc::memory::ZoneDataUpdater::add
 (this=0x76fc20, rrset=..., sig_rrset=...) at zone_data_updater.cc:376
 #6  0x00000000004dc19d in (anonymous
 namespace)::ZoneDataUpdaterTest_rrisgForNSEC3Only_Test::TestBody
 (this=0x76fbc0) at zone_data_updater_unittest.cc:189
 #7  0x00007ffff4f1bcff in
 HandleSehExceptionsInMethodIfSupported<testing::Test, void>
 (method=<optimized out>, object=<optimized out>,
     location=<optimized out>) at src/gtest.cc:2090
 #8  testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
 void> (object=0x76fbc0, method=&virtual testing::Test::TestBody(),
     location=0x7ffff4f1c9cb "the test body") at src/gtest.cc:2126
 #9  0x00007ffff4f13509 in testing::Test::Run (this=0x76fbc0) at
 src/gtest.cc:2162
 #10 0x00007ffff4f135d6 in testing::TestInfo::Run (this=0x762030) at
 src/gtest.cc:2338
 #11 0x00007ffff4f13716 in testing::TestCase::Run (this=0x761e10) at
 src/gtest.cc:2445
 #12 0x00007ffff4f13abe in RunAllTests (this=0x753250) at src/gtest.cc:4237
 #13 testing::internal::UnitTestImpl::RunAllTests (this=0x753250) at
 src/gtest.cc:4145
 #14 0x00007ffff4f1b8df in
 HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
 bool> (method=<optimized out>, object=<optimized out>,
     location=<optimized out>) at src/gtest.cc:2090
 #15
 testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
 bool> (object=0x753250, method=
     (bool
 (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl *
 const)) 0x7ffff4f137a0 <testing::internal::UnitTestImpl::RunAllTests()>,
     location=0x7ffff4f1dab8 "auxiliary test code (environments or event
 listeners)") at src/gtest.cc:2126
 #16 0x00007ffff4f12b7e in testing::UnitTest::Run (this=<optimized out>) at
 src/gtest.cc:3874
 #17 0x00000000004e553c in isc::util::unittests::run_all () at
 run_all.cc:87
 #18 0x000000000042f63a in main (argc=1, argv=0x7fffffffd658) at
 run_unittests.cc:25
 }}}

 From a quick look, nsec3_data might be uninitialized when being used here.
 But I didn't look how that could happen.

 I'm not aware of using shlib, and emerge (gentoo's package manager) does
 not see any package with name or description of shlib.

 Does the backtrace help, or should I try digging

 Also, maybe pass the ticket to me if you have further questions. I noticed
 the question mostly by accident.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2420#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development