On Wed, Dec 27, 2017 at 6:31 PM, James E. King, III <jk...@apache.org> wrote:
> On Wed, Dec 27, 2017 at 6:06 PM, Roger Meier <ro...@bufferoverflow.ch> > wrote: > > > I would be happy to port tests from boost-test to googletest > > Not certain I see a benefit there. Replacing one third party library for > another... [Not saying this should convince you, but this is how I debug basically all low-probability concurrency-related bugs -- don't bother understanding it, just add log-lines and run gazillions of test-replays.] Two advantages: (1) at least with boost-test 1.58.0, it seems like even running individual tests doesn't work. But the real winner is (2) googletest supports out-of-the-box "gtest-parallel", which is a way to run googletest tests that are suitably non-self-interfering in parallel, many copies, many times, keeping track of which ones fail. The way I found the bug in THRIFT-3877 was *not* to go understand the code, but instead to iteratively (a) add log-lines with glog (b) rerun with gtest-parallel As I added log-lines, the probability of the bug occurring dropped (b/c it always does ;-) (but also b/c the log-lines "stretched-out" some of the executions enough for packets to make it across the "network" (== "lo0 network" ;-) But I just upped the gtest-parallel "# times to run test" to ensure that I hadn't scared the bug away. I didn't actually understand what was going wrong, until I had it pretty much nailed in a log of the incident in excruciating detail. gtest-parallel + logs FTW! --chet--
