Right, i think its always this way with such bugs? Sometimes you have to run them a few hundred times in a loop or whatever. Sometimes it helps to 'make your machine busy' by doing somethign crazy in another shell window, like run lucene tests.
My point is just that if you hit a failure coming from multiple threads in basetokenstreamtestcase, it should nearly always mean that its a thread safety issue, because it previously just ran the the same "seed" through single-threaded. Nobody wants to debug threads if its a simple bug that has nothing to do with thread safety. So if you find its not a thread safety issue, then basetokenstreamtestcase has a bug. On Fri, Mar 21, 2014 at 2:05 PM, Benson Margulies <bimargul...@gmail.com> wrote: > To be clear, it's my own code that is amiss here, nothing in Lucene itself. > > I just fixed a thread-safety bug, but I just saw another failure, and > I'm pulling my hair because it refuses to repro. > > > On Fri, Mar 21, 2014 at 2:03 PM, Robert Muir <rcm...@gmail.com> wrote: >> Do you have a stacktrace of where in BaseTokenStreamTestCase that it hit? >> >> We refactored the asserting here, to always test with a single thread >> *first*, then with multiple threads. >> >> So if you are failing in the multithreaded part, it means you have a >> thread safety issue... >> >> (as long as this part of the base test class is working, and i hope it >> still is, i havent seen anything crazy to indicate otherwise, and i've >> been in TestRandomChains for a few hours this week) >> >> On Fri, Mar 21, 2014 at 1:57 PM, Benson Margulies <bimargul...@gmail.com> >> wrote: >>> I'm fighting with a test that uses the random analysis chain testing. >>> It does not repro when I pass in the usual collection of -D's. I think >>> that the reason is to do with threads; the failure is always on a big >>> multicore build machine. >>> >>> Are there any more of those Carrot control -D's that change how many >>> threads are in the act? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
