BIND 10 #2669: Valgrind issues

[BIND 10 Development]

#2669: Valgrind issues
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  task          |  UnAssigned
            Priority:  medium        |                       Status:
           Component:  Unclassified  |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130219
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:3 jelte]:

 Hmm, I'm afraid I don't know how to review this branch...

 > I got rid of most of the fork()-related issues by adding --child-silent-
 after-fork=yes (technically this could result in missed issues in forking
 unit tests, but currently it is reporting leaks from stack allocations...)

 Could you elaborate a bit more?  What does "leaks from stack
 allocations" mean?  Specifically what kind of error was reported for
 which part of the code?  Isn't there any false negatives by
 suppressing this? (and if there is, are you suggesting suppressing
 others at the cost of missing them is more beneficial?)

 > I ran it on the centos machine, and there were two issues left in my
 checkout:
 > - one was an uninitialized memory block, fixed in the second commit

 This one basically looks okay, although I'd do
 {{{#!cpp
             memset(data_, 0, sizeof(data_));
 }}}
 Another note is that you may need to include <cstring> for memset.
 And, to this end, I'd personally even use `vector<uint8_t>` for data_
 (then we won't have to worry about such low level thing as
 initialization with such source-of-all-evil API as memset).

 > - the other one appears to be inside the specific version of libsqlite
 on that old centos. I think I reported this as well last time, and more
 recent versions don't seem to have this issue. Anyway if we're not gonna
 upgrade, this is the repression I used on the centos buildbot:

 I'm not sure about how to comment on this.  Are you suggesting we
 upgrade sqlite3 on the buildbox that runs valgrind?

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