BIND 10 #2888: msgq unittest failure on OpenBSD

[BIND 10 Development]

#2888: msgq unittest failure on OpenBSD
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  UnAssigned
            Priority:  very high     |                       Status:
           Component:  msgq          |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  3             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 Replying to [comment:2 jinmei]:
 > I'm not convinced that abusing unit tests this way is the best
 > approach, but as the existing tests already passed the review-merge
 > process I won't fight against that at this moment.

 Well, propose a better approach. As I say, we could implement it using
 lettuce.
 But then, we would need the terrain to connect to msgq itself (not talk
 through
 bindctl) and send messages and receive messages. And then the test would
 be
 mostly the same, just with the additional layer of the terrain. The
 launching
 could have the same bug as this one as well. And, once we start
 implementing
 the stress tests, we need loops, which are not really available in
 lettuce, and
 we will need some various broken scenarios for the error testing, which is
 mostly a new lettuce statement for each error case. So I don't think we
 would
 gain anything by using lettuce here.

 Do we have any other approach?

 And, yes, I believe this level of tests really does need to start full-
 featured msgq.

 Anyway, I pushed the fix. I believe it should work, because it actually
 tries
 to connect. I did run the test 1000 times and it didn't fail here (even
 without
 the wait there, which could increase the chance of race condition). I'll
 also
 ask for the branch to be put into the build bot. But if anyone had a
 reliable
 way to reproduce, I won't say no for him trying it.

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