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
particular, renamed mc_replace_strmem.c as mac_replace_strmem.c; the 'mac'
prefix indicates it's shared between Memcheck and Addrcheck.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1774
had forgotten that some errors (PThread errors) are found by the core, rather
than skins and so the skin shouldn't be involved in handling them. This commit
fixes the problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1770
