On Fri, Nov 30, 2012 at 02:43:12PM +0400, Konstantin Serebryany wrote:
> I've upstreamed most of your changes, please take a look.
> Looks like we will be able to use libsanitizer/merge.sh to update the
> test code as well.
Thanks.
> > #ifndef ASAN_AVOID_EXPENSIVE_TESTS
> > (TEST(AddressSanitizer, ManyThreadsTest) {
> > ...
> > }
> > #endif
> > and I could in asan_test.C add:
> > // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS" { target { !
> > run_expensive_tests } } }
>
> I can add ASAN_ALLOW_SLOW_TESTS to asan_test_config.h and then #if
> ASAN_ALLOW_SLOW_TESTS around ManyThreadsTest.
> I did not do it yet, because I would like to understand why it's slow.
> On my box (with clang+gtest) it runs in 0.6 seconds, and the entire
> test suite takes 60 seconds.
> Note that when running gtest tests in llvm test harness the tests are
> sharded, so on a multicore machine the test takes < 10 seconds.
Seems it is quite random, often
./asan_test.exe AddressSanitizer_ManyThreadsTest
completes within a second, but from time to time, it takes 30 seconds
instead, and occassionally even much more than that (those 4 minutes I saw).
I'm using the default distro ulimit -u:
1024
and I have certainly more than 24 other processes running around, and
furthermore the test doesn't bother to check return values of e.g.
pthread_create (which is IMHO quite important, otherwise the thread handle
is some random garbage and calling pthread_join on it is risky).
So, perhaps we shouldn't disable the test completely for
#ifdef ASAN_AVOID_EXPENSIVE_TESTS, but rather use 32 even for 64-bit
architectures if it is defined. And/or do getrlimit (RLIMIT_PROC, &rl)
and max the number of threads with say half or quarter of the maximum.
I remember the go testsuite did something similar at one point, also wanted
to create around 1000 threads, and that resulted for months in weirdo
random testsuite failures elsewhere during parallel testing, when the go
testcase created too many threads and then there were no further user
processes allowed for the user that was testing it and so fork failed
somewhere. My preference would be both using 32 by default and
more only when requesting expensive tests, and limit it with RLIMIT_PROC
half or quarter when running expensive tests. And definitely, please
adjust all test to handle pthread_create failures. In this particular
test it should just stop the loop and do the next loop only as many threads
as have been successfully created. In other cases it might be just return;
or similar.
Jakub
