BIND 10 #2349: Valgrind issues

[BIND 10 Development]

#2349: Valgrind issues
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  UnAssigned
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20121023
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned
 * status:  assigned => reviewing


Comment:

 OK, two potentially controversial changes here, but it does fix all of the
 remaining valgrind issues on my system.

 The first one is that every death test only runs EXPECT_DEATH if it is not
 running under valgrind; the valgrind headers offer a macro for this, so
 configure.ac checks if those are available. If so, and if valgrind is
 indeed running, all EXPECT_DEATH tests are skipped.

 The second one makes two classes in lib/resolve/recursive_query.[h]
 public, but they offer only a destructor (the details are hidden behind
 Pimpl, and the constructor is only available to RecursiveQuery objects).
 The biggest drawback is that it now contains two new's instead of one, and
 it does not address the fundamental issue of these objects that need to
 live out of scope without a decent pool manager. In this specific case,
 the unit tests leave out much of the framework and these objects never
 delete themselves, so providing a destructor gives the unit tests a chance
 to clean up.

 IMO the lib/resolve code should be changed to get this right, it either
 needs a pool or a different way to consistently handle upstream
 outstanding queries, that does not need dynamically allocated object with
 no scope.

 But since we're not supposed to put too much work in the resolver right
 now, I think that simply providing an interface for the tests to delete
 them should be enough for now.

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