[Bro-Dev] #846: Tests Failures
Bro Tracker
bro at tracker.bro-ids.org
Tue Jul 10 14:02:57 PDT 2012
#846: Tests Failures
----------------------+------------------------
Reporter: robin | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.1
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by robin):
On Tue, Jul 10, 2012 at 16:45 -0000, you wrote:
> Yeah, I don't think that's a big deal, either.
Ack.
> The segfault is at least fixed by the commit in comment:3,
> but the test may still fail in this case,
Ok.
I'm starting to think though that we need a list of reasons which
tests are expected to fail under what circumentances (and how to
identify that that is indeed the case). As we're getting more of them,
it's becoming hard to track (another example: no libgeop triggers
additional reporter messages).
> 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?
That would indeed make a good explanation. That must be a race
condition in the threat termination code. When that happens, do you
see any reporter messages about threads that didn't finish in time?
There's code that aborts a thread forcefully if it doesn't terminate
sufficiently quickly by itself (with "quickly" being a hardcoded value
in MsgThread::OnStop(); not great admittedly ...)
Generally, threading::Manager::Terminate() is the entry point for the
thread shutdown. The output of -Bthreading would be interesting to see
in for a case where output doesn't appear.
Robin
--
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/846#comment:4>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
More information about the bro-dev
mailing list