Remove two pieces of identical code used by Memcheck and Addrcheck, and put
them in a shared place. (They used to be different, when Addrcheck didn't
distinguish between reads and writes, but now they're the same.)
implement a couple more instructions. I've mailed this patch to Julian
and Nick but got no reply. I guess they're okay with it. I tested them
quite a lot so it should be fine.
Removed the Bool 'read_from_file' arg from (what is now)
VG_(parse_procselfmaps)(). If /proc/self/maps needs to be read beforehand, the
code calls (what is now) VG_(read_procselfmaps)() before. Still using the
static buffer which is not nice but good enough.
More importantly, I split up VG_(new_exe_segment)() into
VG_(new_exeseg_startup)() and VG_(new_exeseg_mmap)(). This is because at
startup, we were stupidly calling VG_(read_symbols)() for every exe seg, which
parses /proc/self/maps completely in order to load the debug info/symbols for
the exe seg (and any others we haven't already got the symbols for). Despite
the fact that the startup code reads /proc/self/maps to know which segments are
there at startup. In other words, we were reading /proc/self/maps several
times more often than necessary, and there were nested reads, which Stephan
Kulow's recent depth patch fixed (but in a pretty hacky way; this commit fixes
it properly). So VG_(new_exeseg_startup)() now doesn't cause /proc/self/maps
to be re-read. Unfortunately we do have to re-read /proc/self/maps for mmap(),
because we don't know the filename from the mmap() call (only the file
descriptor, which isn't enough).
add suppression about common X11 protocol and ICE errors. Please
scream if you don't like this.. Personally I've never seen a valid
warning and all of them were spurious.
Add patch from Stephan Kulow to solve the following:
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
Added some skin-visible functions that give skins a bit more control over
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.
With -v option, client program's argv[] now printed at startup. Should be
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.
Made Addrcheck distinguish between invalid reads and invalid writes (previously
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.
Increase VG_N_FORKHANDLERSTACK from 2 to 4. For reasons known only to
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.
construct_error(): strdup the supplied s (string) param which gives
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.
Changed the behaviour of realloc() in Memcheck, Addrcheck and Helgrind.
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.
A big commit size-wise, but small concept-wise: removed the ThreadState type
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.
Use init_ExeContext_storage instead of relying (unintentionally) on
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 :-)
Fix a problem in VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH)(): when removing the
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.
Changed behaviour of VALGRIND_COUNT_LEAKS slightly. Previously, the numbers it
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).
Truncate the cachegrind.out.<pid> file, if it already exists. It wasn't doing
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.
Added overlap checking to Addrcheck, mostly just moving things around. In
particular, renamed mc_replace_strmem.c as mac_replace_strmem.c; the 'mac'
prefix indicates it's shared between Memcheck and Addrcheck.
This commit fixed some bugs in error and suppression handling. Basically, I
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.
Add patch from Sami Liedes <sliedes@cc.hut.fi> making GDB use more flexible:
--gdb-path=/path/to/gdb allows running some alternate GDB
--input-fd=<n> allows reading input from some fd other than stdin
I even updated the docs :-)
In vg_memory.c, startup_segment_callback, fix initialisation ordering
problem which caused the leak checker to misbehave following recent
PLT-bypass workaround.
In short, it is an error to announce to the skin, segments found which
belong to the low-level memory manager, because the skin may then mark
them as accessible to the client. This is wrong, and the client
should only acquire accessible memory via malloc etc and stack
movement. Now we carefully avoid mentioning any segment belonging to
the low level memory manager.
Take the opportunity to improve VG_(within_m_state_static) so that it
also detects pointers within the thread table. This can reduce the
number of blocks the leak checker spuriously thinks are still
reachable.
add_MAC_Chunk: mark shadow block as off-limits to the client so that
the leak checker doesn't see the pointer to the real block. As
detailed in the comment in this function, this must be masking a
deeper memory management bug.
A new implementation of pthread_once() which I believe should comply
properly with POSIX, and not get assertion failures when the same
thread makes nested calls to pthread_once with different once_control
pointers.
Add a new mechanism for intercepting calls, which doesn't depend on
the vagaries of the dynamic linker. In particular this has been
devised so as to work around errno/h_errno/resolver-state misbehaviour
caused by excessive PLT bypassing in glibc-2.3.2: we need to intercept
calls to __errno_location(), __h_errno_location() and __res_state(),
in threaded programs, but we can't always do that because some calls
made internally within glibc-2.3.2 bypass the PLT.
New mechanism is:
- In vg_symtab2.c, VG_(setup_code_redirect_table), search the
symbol tables to find the entry points of the above functions,
and find the corresponding entry points replacements in our
vg_libpthread.c. Put these pairs into a table,
VG_(code_redirect_table).
- In vg_translate.c, VG_(translate), consult the table each time
a translation is made, and if a hit is found, translate from
the substitute address instead.
This seems to make corecheck/tests/res_search work properly,
although for some as-yet unknown reason breaks the corecheck
skin. All other skins appear unaffected.
One unfortunate effect is that the lazy debug info scheme is now
nullified, since we always need to read debug info in order to
generate the redirection table.
projects / thirdparty / valgrind.git / log
