BIND 10 #2275: work on valgrind backlog

[BIND 10 Development]

#2275: work on valgrind backlog
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20121009
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  Core
                   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 => jinmei


Comment:

 Replying to [comment:8 jinmei]:
 >
 > > > '''labelsequence_unittest.cc'''
 > > >
 > > > My valgrind (3.8.1) doesn't complain about this.  What's wrong with
 > > > the original code?
 > >
 > > uninitialized memory; the constructor checks both offsets and label
 length in one loop; so even though it failed on the offset being wrong,
 the label data memory was uninitialized.
 >
 > Ah, right.  The original code was really buggy and valgrind correctly
 > identified it.
 >

 well, it would always hit the check and exception, but due to the
 initialized memory, it was essentially random which of the two parts of
 the if-check it would hit (so yeah, it was buggy, and certainly not doing
 what it intended, but it would never visibly fail)

 > Hmm, on a closer look, I suspect the original code was really buggy,
 > and the *right* fix is this:
 >
 > {{{#!cpp
 >         strncpy(socket_address.sun_path, path_,
 >                 sizeof(socket_address.sun_path));
 > }}}
 > (without the explicit memset)
 >
 > The previous version used the length (strlen) of path_, so sun_path
 > could actually be non-nul terminated even if path_ is short enough.
 > (another reason why we should generally avoid such low-level APIs).
 >
 > I believe with this change valgrind stops complaining about this.

 ah, doh, of course.

 Changed.

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