[re-sending so that it gets to the list] asan's design choice is to hard crash on the first error.
Doing many asan checks in the same process might become too messy too soon. I wouldn't try to implement it myself. Playing with longjmp in asan is not the best idea because asan intercepts longjmp and in fact it does have some locks around __asan_report_* That's why we really like the death tests that run every check in a separate process. Why depending on gtest is bad? --kcc On Fri, Nov 9, 2012 at 11:16 AM, Jakub Jelinek <[email protected]> wrote: > > On Fri, Nov 09, 2012 at 08:13:12PM +0100, Jakub Jelinek wrote: > > On Fri, Nov 09, 2012 at 11:05:37AM -0800, Wei Mi wrote: > > > gtest integrate multiple tests into the same file with each test being > > > a single line check. I cannot think out a method to migrate it to > > > dejagnu without using gtest, except splitting a single gtest file to > > > multiple files with each file per test. asan has about 130 tests so > > > have to write 130 files which will be a doable but painful task. > > > > See the glibc _FORTIFY_SOURCE check I've referenced, there it is 3 lines > > per test expected to crash, but could be done in a single macro too. > > If the failure can be intercepted, it can be done in a single process > > (e.g. > > SIGABRT can, _exit can't that easily), otherwise perhaps say way to skip > > previous tests and communicate with dejagnu how many times it should run > > the > > executable. > > And quick grep shows that one can call __sanitizer::SetDieCallback > and supposedly, if ASAN doesn't hold any locks when it calls Die() that > would prevent it from functioning further, we can just longjmp out from > the > callback. > > Jakub
