and Nick but got no reply. I guess they're okay with it. I tested them
quite a lot so it should be fine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1834
message if so. If anyone thinks this will break anything, please yell.
Updated FAQ #5 correspondingly, added info on how to combine static and dynamic
libraries.
MERGE TO STABLE(?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1831
Renamed:
VG_(read_procselfmaps_contents)() --> VG_(read_procselfmaps)()
VG_(read_procselfmaps)() --> VG_(parse_procselfmaps)()
VG_(read_symbols)() --> VG_(read_all_symbols)()
VG_(read_symtab_callback)() --> VG_(read_seg_symbols)()
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).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1830
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
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
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
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
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
--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 :-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1754
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1751
properly with POSIX, and not get assertion failures when the same
thread makes nested calls to pthread_once with different once_control
pointers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1746
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1743
up-to-and-including the '}' when the number of callers is >=
VG_N_SUPP_CALLERS. (Jeffrey Stedfast)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1728
'predict not taken' when it appears before a conditional branch.
Valgrind 1.9.6 doesn't know how to handle this. The appended patch
makes it ignore the prefix in this case, which should be safe.
A DS segment override means 'predict taken', but valgrind already
ignores that on a conditional branch, so nothing needs to be done.
(Zack Weinberg)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1720
