Ok, I think I got it. That is a fun race condition that I did not think of while writing the test. At the moment, the test depends on the fact that the event that prints the output will not be called before all lines have been handled by the input-manager.
However, while this apparently is true in most cases - it does not always have to be true. Sometimes, the first queued events are handled by the bro scripting layer before the input manager got all lines from the reader. Hence, the table output differs. Will commit a fixed version in a minute :) On Mar 7, 2013, at 8:09 PM, Bernhard Amann <[email protected]> wrote: > > On Mar 7, 2013, at 5:07 PM, Robin Sommer <[email protected]> wrote: > >> >> >> On Thu, Mar 07, 2013 at 19:02 -0600, [email protected] >> wrote: >> >>> scripts.base.frameworks.input.tableevent ... failed >> >> This one keeps failing frequently (but not always) for me too. Anybody >> up for seeing if it can be fixed? > > I will take a look at it... > > > _______________________________________________ > bro-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
