BIND 10 #2669: Valgrind issues

[BIND 10 Development]

#2669: Valgrind issues
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  task          |  jinmei
            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
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:7 jinmei]:
 >
 > This seems to me to be another reason why it's a bad idea to try to
 > invent such low level wheel ourselves:-)  That aside, in this
 > particular case, can't we delay defining of `sync` and `locker` after
 > fork and have the child wait on the pipe until the parent acquires the
 > lock?  But, even if it works, other cases would have to be handled
 > case-by-case basis, so it may not help much.
 >

 I had looked into that but the problem is more fundamental than that; we'd
 need to get rid of exit(), and even that may only solve a few issues
 (valgrind can't seem to handle threads either, I just found out on my
 centos instance)

 > Since I don't know how many other cases we have and how difficult they
 > are to work around, it's hard to say whether the global suppression is
 > a reasonable choice.  If the cases are not so many (and assuming the
 > fork generally happens in unit tests), another possibility is to skip
 > these test cases via gtest filter when running valgrind on buildbots.
 > That way, we can possibly remove the exceptions one-by-one.
 >

 Actually, this reminded me of a similar issue in death tests (Also for
 similar reasons), and for now I have the approach from there; check if
 valgrind is running and if so skip automatically.

 Since this also skips on systems where it might work (or appear to work,
 as i suspect that technically valgrind is correct) it may not be the very
 best solution, but at least we don't have to muck around with filters and
 name conventions (and should we decide to want to go that way, it should
 be relatively easy to grep for calls to runningOnValgrind() now).

 So latest push has more runningOnValgrind() checks (and a few include
 order fixes), and if we don't like that the alternative I can see is to
 rename those tests to something like <test_name>_SKIP_FOR_VALGRIND, and
 set that up as a buildbot filter.

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