mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-10 21:47:06 +00:00
6bd8cf1eae
information about the stack traces recorded by Valgrind. This can be used to analyse one possible cause of Valgrind high memory usage for some programs. At work, a big set of regression tests crashed out of memory under Valgrind. Two main causes for out of memory were identified: 1. big memory usage for stacktrace (exe contexts) recording by Valgrind 2. big number of partially initialised bytes. This patch adds a gdbsrv monitor command that output (very) detailed information about all the recorded exe context. This has been used to analyse the problem 1. above, showing the following identified causes for a (too) big nr of execontexts: A. When the JIT handles an unknown SP update, even when --track-origins=no, an execontext is (uselessly) created and recorded to track the (never used) origin of some uninitialised stack memory. This creates a whole bunch of 'one IP' execontexts. B. same problem in handling some system calls (at least the brk system calls always records an origin, even when --track-origins=yes). C. The Valgrind unwinder cannot properly unwind some stack traces. It unwinds a few frames, then go bezerk and stops at a "random" IP. This then causes the same "logical" stacktrace to be truncated and records thousands of times with this "differentiating" last IP. For problem cause 2 above ( a lot of partially initialised bytes), the idea is to similarly add another gdbsrv commands that will output statistics about which stack traces are causing a lot of uninitialised bytes. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13220