scream if you don't like this.. Personally I've never seen a valid
warning and all of them were spurious.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1826
read_procselfmaps calls *record_mapping which
is startup_segment_callback for init_memory. But this
again calls through read_symbols read_procselfmaps
again with read_from_file == True. But this overwrites
the internal buffer and causes parsing errors.
(What makes the error a bit funny is that valgrind
wouldn't have catched that error afaik :)
Anyway: our solution is to forbid read_from_file from
with callbacks
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1820
how stack snapshots are taken and printed; they can be used in preference
to VG_(get_ExeContext)() and VG_(pp_ExeContext)(). These are used by
Massif, my heap profiling skin.
Changed --num-callers to allow a backtrace size of 1.
Added code so that when Valgrind fails to disassemble an instruction, the
instructions line/file and address are printed out, which makes it easier to
work out where and what it is. Required the stack snapshot changes above.
MERGE TO STABLE?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1819
useful when trying to interpret users' problems. Each argv is printed on a
separate line, to make it extra clear where each one starts and ends.
MERGE TO STABLE (PLEASE!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1816
was just saying "invalid memory access").
Added a regression test for this, for memcheck and addrcheck. Also made
Addrcheck use Memcheck's fprw regtest. Was able to remove the not-very-useful
'true' test for Addrcheck now that it has a couple of real tests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1815
count. Added a regression test for it.
Updated the basic test stderr filter to strip out line numbers from
vg_intercept.c
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1812
MERGE TO STABLE (along with several other FAQ changes I've made recently but
forgot to write this note on)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1804
itself, pth_atfork1 and 2 fail on R H 7.3 for a size-2 stack, but only
with certain skins. Don't ask me.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1789
extra info about some kinds of errors. It was being allocated on the
stack by complain2/3 in mac_malloc_wrappers.c.
If the constructed error is found to be a duplicate, free the strdup'd
space. That limits the worst-case space leak to one strdup'd string
for each different error we keep track of, and the latter by default
is limited to 300.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1785
Previously, when realloc() was asked to make a block bigger, the ExeContext
describing where that block was allocated was increased; however, if the block
became smaller or stayed the same size, the original ExeContext remained. This
is correct in one way (that's where the memory manager actually parcelled out
the block) but it's not very intuitive. This commit changes things so the
ExeContext of a block is always changed upon realloc(). I added a regression
test for it too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1783
from skin's view, replacing all instances with ThreadId. Much cleaner. Had to
change the way VG_(get_ExeContext)() worked a little. Changed the core/skin
major interface because this breaks the old version. Also fixed a few minor
related things here and there.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1782
properties of 'static'. Also, de-globalise this function. Some days
I really yearn for a proper module system in C. Come back Haskell,
all is forgiven :-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1781
added paths, it was taking out the colon between the removed entry and the
following, which meant the following was interpreted as having a big chunk of
whitespace at the start, which broke some things.
eg. was:
"foo:bar" --> " bar"
now:
"foo:bar" --> " :bar"
in which case " " is considered a separate path in it's own right, albeit one
that doesn't mean anything.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1779
returned (bytes leaked, dubious, etc) were incremented for every leak check
performed. So if you called VALGRIND_DO_LEAK_CHECK twice in a row, the totals
would be updated twice by the same amount. This was a bit silly. So now
COUNT_LEAKS just returns the numbers of bytes leaked found from the previous
leak check. I even updated the docs, and changed the regression test so old
version fail but the new version passes (by doing two DO_LEAK_CHECKS in a row).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1778
this, which meant that if a shorter file of the same name was written, the old
contents past the new end would remain, which would be bad. Had (probably)
never happened because the <pid> suffix makes it very unlikely for filenames to
be reused.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1777
