On Tue, Apr 07, 2020 at 06:44:37AM +0800, Qu Wenruo wrote: > On 2020/4/7 上午12:56, David Sterba wrote: > > On Mon, Apr 06, 2020 at 02:11:05PM +0800, Qu Wenruo wrote: > >> Since run_check_stdout() can insert INSTRUMENT, which could easily > >> pollute the stdout, any caller of run_check_stdout() should filter its > >> output before using it. > >> > >> There are some callers which just grab the output without filtering it, > >> most of them are simple inspect-dump commands. > >> > >> To avoid false alert with INSTRUMENT set, just don't utilize > >> run_check_stdout() for those call sites. > >> Since those call sites are pretty simple, shouldn't cause too many holes > >> in the coverage. > > > > I don't like this, it removes a lot of the coverage. The instrument > > tools should provide a way to avoid stdout/stderr pollution, eg. > > valgrind has --log-fd or --log-file. We can add a shortcut that will > > provide some defaults so we can conveniently use 'INSTRUMENT=valgrind'. > > > Then that's too INSTURMENT dependent. Yes, but how many do we use besides valgrind. I have tried gdb with some init script or batch mode to catch crashes, but I can't think of other tools. > What about adding filtering for the mentioned callers? I'm not sure what exactly do you mean, can you send an example?
