This fixes bug 134316: when an program in callgrind does
a fork, callgrind_control does show both now, and they
can be controlled separately.
However, missing in this patch is zeroing of cost centers
directly after the clone syscall in the child.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6082
This callgrind option produces lines starting e.g. with
"jfi" in the profile data files, which specifies a
source file change between a jump source and jump target.
This itself is meaningless for callgrind_annotate, as
it can not show jump information in its annotation.
However, such "jfi" lines can contain important mapping
info for a (file ID, file name) tuple - which leads to
further warnings and problems if ignored.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6064
This checks all of callgrinds client requests,
and accordings actions (zero/dump) in different states
(collection on/off, instrumentation on/off).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6058
This bug shows up when callgrind dumps data of a BB with 0 instructions
(the segfault only appears on x86_64; for x86 we were "lucky").
"BB with 0 instructions" happens when you switch on instrumentation
(and callgrinds call graph tracing starts with an emtpy shadow call
stack) in the middle of a run: Whenever the shadow callstack
is empty, but callgrind sees a return instruction (ie. a shadow
callstack underrun), it creates an artifical BB which is faked to
have called the function we are returning from.
This way, the call arc is noted and will appear in the dump.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6053
When instrumentation mode is switched off, we want to fully
reset callgrinds internal execution state, which includes
the shadow call stack and function stack for context generation.
The latter was not completely reset before.
The bug showed up when switching the instrumentation mode on for
the second time, leading to
Callgrind: callstack.c:211 (vgCallgrind_push_call_stack):
Assertion 'current_entry->cxt != 0' failed.
This commit also improves debug output a little bit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6045
I just noticed that this is still a little wrong, as counts for e.g.
"strcmp" from libc and "strcmp" from ld.so will make up only one entry,
with the object name randomly choosen... but otherwise, it matches
with the data shown by KCachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6044
trash some other segment as a result of the expansion. This fixes
#129866. I don't know if it is a good solution though. Causes
none/tests/mremap{,2} to fail now, although I think it is still OK.
mremap really is a semantic disaster area.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6003
as SkResvn rather than SkFree, since doing otherwise causes the area
above aspacem_maxAddr - which starts out as SkResvn - to be polluted
with SkFree bits. Fixes an assertion failure found by Alex Bennee
(users list, 9 Aug 06).
Also allow the preener to merge fixed-sized SkResvns so as to avoid
fragmentation that otherwise results.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6001
they had size one. Otherwise they appear to cover no address space,
so no pointers to them are ever found, and so they are always
incorrectly marked as leaked.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5994
