Moving to list. On Mon, Jan 17, 2011 at 10:21 PM, Gregory Farnum <gregf@xxxxxxxxxxxxxxx> wrote: > On Mon, Jan 17, 2011 at 9:42 PM, Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: >> I guess the first question is a philosophical one. Do we want to allow >> people to use things like the heap checker or valgrind on unit tests? >> I think we should, since it will be add to the usefulness of unit >> tests in general. The second question is, if we do want to do that, >> how should we go about it? I think you have the right idea with making >> common_init more granular, so that we can initialize just the heap >> checker or signal handler without pulling in the whole thing. If you >> agree, let's open a bug to get this taken care of, since you >> apparently didn't like my "just call common_init" solution. > > Unit tests probably ought to be simple enough that you don't need a > full backtrace handler. Certainly it doesn't need tcmalloc's heap > checker. Well, nobody needs a backtrace handler until his or her code has a bug. Then everyone needs one, whether the code is simple or not. I'm trying to think ahead to the future here, where we might see scenarios like "make check got a segfault on the continuous build server, but it runs just fine locally. Gee, I wonder what the problem is?" Unfortunately, stuff like this happens a lot. Uninitialized memory is often 0, and things may work "accidentally." malloc(<large random number>) may work-- if your computer is beefy enough. > If we do want some of our other advanced features, I think we > should add them in individually as otherwise it becomes too easy to > pollute our unit tests with unexpected setup bits. I agree completely. That's why I talked about "making common_init more granular." regards, Colin -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
