It's normal for valgrind to slow things down a lot. One thing you can do to at least improve the quality of the errors you get is to use the suppressions file in util/valgrind-suppressions. The python interpreter does a lot of things which upset valgrind, and this tells valgrind mostly to ignore things it sees there. Also, make sure you build gem5 with the --without-tcmalloc scons option. tcmalloc is an alternative heap implementation which replaces the one valgrind instruments, so if you don't do that, you won't actually check anything.
Gabe On Tue, Sep 7, 2021 at 2:19 PM Sindhuja Gopalakrishnan Elango via gem5-users <gem5-users@gem5.org> wrote: > Hi Community, > > I ran into bad_alloc issues in GEM5 with the full system simulation of > SPEC 2006 benchmarks. > > Suspecting a memory leak, I wanted to use valgrind to understand better. > > > > Without valgrind option, it takes less than 10 minutes for kernel to boot > and also run the 400.perlbench/attrs benchmark. > > But with valgrind, it has crossed 2 hrs and the kernel hasn’t yet booted. > > > > Usage: > > valgrind --log-file=attrs.val.txt --error-limit=no $GEM5_CMD > > > > I would like to know if this slowdown is reasonable with valgrind? > > And do you have any suggestions for a memory leak detection tool that is > faster than valgrind and works well with gem5? > > > > Appreciate your time and effort. Thanks much. > > > > Best Regards > > Sindhuja > > > > > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
