[Bro-Dev] #846: Tests Failures

[Bro Tracker]

#846: Tests Failures
----------------------+------------------------
  Reporter:  robin    |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  High     |  Milestone:  Bro2.1
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------

Comment (by jsiwek):

 > {{{
 > istate.bro-ipv6-socket … failed [Fails if IPv6 connectivity not
 available (fw in this case); can we test for that somehow? Otherwise, fine
 to leave as it is for now.)
 > istate.broccoli-ipv6-socket … failed [Same]
 > }}}

 Yeah, I don't think that's a big deal, either.  They could probably extend
 their `@TEST-REQUIRES` to check if netcat is available and can do a
 connection over `::1`, but maybe it's actually more informative for the
 test to fail than to just skip.

 > {{{
 > core.dns-init [Adam; when using dnscrypt from OpenDNS]
 > }}}

 The segfault is at least fixed by the commit in comment:3, but the test
 may still fail in this case, at least with the current OS X DNSCrypt
 client, because the local proxy is giving DNS responses with extra data at
 the end which causes a call to `ns_initparse()` in `nb_dns.c` to return -1
 and set `errno` to `EMSGSIZE`, giving us warnings like:

 {{{
 NB-DNS error in DNS_Mgr::WaitForReplies (ns_initparse(): Message too long)
 }}}

 I thought about trying to handle this special case by also checking for
 whether `ns_initparse()` was able to parse at least one answer section
 before failing and then just go forward with that, but it didn't seem like
 a great idea (I'm not sure it's "right" to trust things in the returned
 `ns_msg` buffer when there's an error, I couldn't find examples in the
 wild of any code bases doing that).

 But in the latest https://github.com/opendns/dnscrypt-proxy, the proxy is
 at least not returning these DNS responses with extra data at the end, so
 it works fine with Bro.

 > {{{
 > core.disable-mobile-ipv6 ... failed
 > }}}
 > I've never seen that one fail before?

 Is that persistent or transient for you?  I think it probably is due to
 the same issue causing the following group of failures:

 > {{{
 > core.checksums … failed [Gilbert, Matthias; non-determinisitc]
 > scripts.base.protocols.smtp.basic [Matthias; with clang]
 > scripts.base.frameworks.logging.rotate-custom [Matthias; with clang]
 > }}}

 I don't think Clang is a culprit in any of these, I was able to get an
 occasional failure using GCC on OS X.  For any given test, it seemed like
 I could run it hundreds of times serially without getting a failure, but
 when increasing the load on the system (e.g. running more tests in
 parallel), the chances of getting a failure also increased.  And the
 failures all looked like they were due to not writing out a log file, so
 my hunch is it's a general issue with the new threaded logging and not
 anything particular to these specific tests.  Any idea what to start
 looking at?

-- 
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/846#comment:4>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker