At many places, we have:
VG_(fun(a,b,c))
instead of
VG_(fun)(a,b,c)
So, fix these cases, found using:
grep -n -i -e 'VG_([a-z][a-z0-9_]*[^a-z0-9_)]' *.c */*.c */*/*.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15776
slot to 1. Rather do that in add_segment which is where the segment
refering to that name actually comes into existence.
Properly handle the case in add_segment where the to-be-added segment
and one (or more) of the segments it replaces have the same name
This may occur when doing a mremap.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15761
aspace mgr provides VG_(am_mmap_client_heap) that mmaps memory and
marks it as being client heap memory. Marking superblock segments used
for malloc/free as heap is critical for correct leak search: segments
mmap-ed for malloc/free cannot be considered as part of the root set.
On the other hand, other mmap-ed segments cannot be marked as client
heap, otherwise these segments will not be part of the root set, and
will not be scanned.
aspacemgr merges adjacent segments when they have the same characteristics
e.g. kind, RWX and isCH (is client heap) must be the same (see function
maybe_merge_nsegments).
However, VG_(am_mmap_client_heap) has a bug:
* it first mmaps a normal segment (not marked as heap) using
VG_(am_mmap_anon_float_client)
* it then searches the segment that contains the just mmap-ed address and
marks it as heap.
The problem is that VG_(am_mmap_anon_float_client) has already
possibly merged the new segment with a neighbour segment, without
taking the to be marked isCH into account, as the newly allocated memory
has not yet been marked as Client Heap. So, this results in some memory being
marked as client heap, while it in fact is not client heap. This
memory will then not be scanned by the leak search.
The fix consists in having VG_(am_mmap_anon_float_client) and
VG_(am_mmap_client_heap) calling a new function
am_mmap_anon_float_client, which will mark (or not) the new segment as
client heap *before* trying to merge it with neighbouring segments.
Then the new (heap) segment will only be merged with neighbours that are also
client heap segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15759
Namely those with a file name and an inode number but without major
and minor device numbers. See for instance https://bugs.kde.org/124528#c11
This patch also recognises segments with a file name as FileV segments
(which is what valgrind used to do prior to r5818).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15632
Solaris runtime linker allows to run dynamically linked programs indirectly, as:
ld.so.1 <dynamic_executable>
This is now possible under Valgrind as well.
Fixes BZ#351858.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15607
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
putting them into a string table.
This patch adds reference counting to segment names and frees them
when they are no longer used. The so freed memory can be reclaimed to
store future segment names.
New file coregrind/m_aspacemgr/aspacemgr-segnames.c which has all the
code dealing with segment names. Carved out of aspacemgr-linux.c
Detailled comments in the code.
Fixes BZ 344559.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15073
be VKI_PAGE_SIZE. That follows from the requirement that
the address ought to be page aligned and > 0.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15042
for command line options does not need to know what addresses are valid
for aspacem_minAddr.
That information should be hidden in the address space manager.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15040
The function is used in VG_(client_syscall) to avoid extending the stack
when it is clear that the current value of the stack pointer does not
point into a segment that looks like a stack segment.
See the comments in the code there.
As a side effect of this we can now revert r15018 which increased
the stack size of the alternate stack in memcheck/tests/sigaltstack.c.
The reason is that the belief at the time: "alternate stack is too small"
was not correct. What instead happened was that VG_(client_syscall) called
VG_(extend_stack) without need (the syscall was tgkill) and the new stack
pointer happened to be in a file segment.
In other words: the current stack pointer was still within the alternate
stack, i.e. the alternate stack was (barely) large enough.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15034
This allows to decrease memory usage when using many threads,
if no big stacksize is needed by Valgrind.
If needed (e.g. for demangling big c++ symbols), the V stacksize
can be increased.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15004
VG_(am_set_segment_isCH_if_SkAnonC).
Rename VG_(am_set_segment_hasT_if_client_segment) to
VG_(am_set_segment_hasT) passing in an address (because that function
cannot possible take a pointer to a *const* segment). Also assert that
the segment containing the address is a client segment. Everything else
is a bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14993
- Tighten up on asserts
- Simplify; as the function grows memory into a free segment, there
cannot possibly be any translations to be discarded. Free segments
do not have translations. sane_NSegment will make sure.
- Change the prototype to take in the start address of the mapping and
return a pointer to the resized segment. Previously, the code
ok = VG_(am_extend_map_client)( &d, old_seg, needL );
if (!ok)
goto eNOMEM;
VG_TRACK( new_mem_mmap, needA, needL,
old_seg->hasR, old_seg->hasW, old_seg->hasX,
was examining old_seg->hasR etc even though VG_(am_extend_map_client)
stated that *old_seg was invalid after the function returned.
That wasn't exactly a problem, but clearly looked wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14963
and VG_(am_get_segment_starts) to indicate which segments
should be collected. That should solve the following problem:
in m_main.c we used to:
seg_starts = VG_(get_segment_starts)( &n_seg_starts );
for (i = 0; i < n_seg_starts; i++) {
Word j, n;
NSegment const* seg
= VG_(am_find_nsegment)( seg_starts[i] );
vg_assert(seg);
if (seg->kind == SkFileC || seg->kind == SkAnonC) {
...
// ... dynamic memory allocation for valgrind
...
}
This caused the vassert(seg) to fire because the dynamic memory
allocation further down the loop changed segments such that a
valgrind segment which used to be non-SkFree suddenly became
SkFree and hence VG_(am_find_nsegment) returned NULL. Whoom.
With this revision we only collect the segments we're really
interested in. For the example above that is all client segments.
So if V allocates memory -- fine. That will not change the layout
of client segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14949
Likewise for VG_(am_next_nsegment). Also make the code similar to
VG_(am_find_nsegment) for easier comprehension.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14937
and rename VG_(am_set_segment_hasT_if_SkFileC_or_SkAnonC) to
VG_(am_set_segment_hasT_if_client_segment). Change it so it handles
all client segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14936
(1) It is always invalid for the incoming segment pointer to be
out of range. Assert that.
(2) Let the compiler do the address arithmetic. They're good at that
and therefore:
(3) No asserts needed to check the result.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14933
The list of segnames was shown with a seq nr,
while each segment was referencing its segname with an offset.
The patch ensures that at all places, both the seq nr and the
offset is output
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14911
The validity of this change follows from the following observations:
(1) There is a single source for allocating and storing segment names,
namely allocate_segname.
(2) For all invocations of allocate_segname the returned value (which
represents the segmant name) is assigned to NSegment::fnIdx.
(3) All but one assignments to NSegment::fnIdx assign allocate_segname.
The single exception assigns -1 in init_nsegment. That function is
called whenever a new segment (named or unnamed) is allocated.
For a segment name to become unused there must be an assignment to
NSegment::fnIdx which was previously assigned a return value from
allocate_segname. There is no such assignment.
It follows that all segment names are in use at all times, hence
SegName::inUse == True for all SegNames. So we can constant fold it
and don't need to represent it.
Pass 3 in preen_nsegments is obsolete as there are no segment names to
garbage collect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14898
address space manager. Callers should neither modify the string nor
free it (as the string resides is statically allocated memory). That
calls for a const HChar *
The type change exposed two bugs. One in m_addrinfo.c and one in
m_debuginfo.c. In both cases the returned string could possibly be freed later
on. So we need to strdup it first. Now fixed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14886
