* Addition of a function to compute size of buffer needed for VG_(mkstemp)
* Use it to dimension buffers for all VG_(mkstemp) calls.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13409
On Ubuntu systems, ptrace_scoping could forbid a process to ptrace another.
This ptrace scoping was already handled for vgdb by using SET_PTRACER
(the valgrind process must be ptraced by vgdb when it is blocked
in a syscall).
set_ptracer is however also needed when the old mechanism --db-attach=yes
is used.
The following changes are done:
* make the set_ptracer logic callable outside gdbserver
* make set_ptracer less restrictive (i.e. allow all
processes of the user to ptrace). This removes a limitation for vgdb.
* call the set_ptracer in the child launched for --db-attach=yes
* cleaned up the ptrace scope restriction message and doc as vgdb
is now working properly by default, even with ptrace_scope enabled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13384
* when SEGV trapped, report the main thread size as an unsigned size_t
* Similar for memcheck overlap errors
For example, for the 2 calls:
memcpy(&a, &a, 2147483648UL);
memcpy(&a, &a, -1); // silently accepted by gcc 4.4.4 -Wall
// while the 3rd arg is supposed to be a size_t
we now obtain (on a 32 bit system)
Source and destination overlap in memcpy(0xbe97113f, 0xbe97113f, 2147483648)
Source and destination overlap in memcpy(0xbef6d13f, 0xbef6d13f, 4294967295)
instead of
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -2147483648)
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -1)
Do not ask me why
memcpy(&a, &a, -1);
is supposed to be accepted/acceptable/valid code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13326
Functionality is provided via the new 3.9.0 arg
--errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors?
[definite,possible]
where kind is one of definite indirect possible reachable all none
that was committed in rev 13170.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13305
Assertion
valgrind: m_transtab.c:674 (find_TTEntry_from_hcode):
Assertion '(UChar*)sec->tt[tteNo].tcptr <= (UChar*)hcode' failed.
failure (encountered on some platforms while running gdbsrv tests).
The problem is related to invalidated entries and the host_extents
mapping between hostcode and the translation table entry.
The problem: when an entry is invalidated, the translation table
entry is changed to status Deleted. However, the host extent array
element is not cleaned up.
If a search for a host code address (find_TTEntry_from_hcode)
finds this entry, the translation table entry in Deleted status
is considered as a 'not found', which ensures that the invalidated
entry is not used (e.g. for chaining).
This is all ok.
However, it might be that this Deleted entry is re-used
(see function VG_(add_to_transtab), searching for a Empty
or Deleted entry.
If the Deleted entry is re-used, then a search for the
dead host code can give a result pointing to the re-used
entry. That is clearly wrong.
Note that it is unclear if this bug can only be triggered
while using gdbsrv or if this bug can be triggered with
just the "normal" invalidation logic of translation.
gdbsrv being a heavy "user" of invalidation, it might
be it helps to trigger the code. Alternatively, as gdbsrv
invalidation is special (e.g. invalidation of some entries
is done during translation of other entries), it might be
the bug is specific to gdbsrv.
In any case, to avoid the bug:
searching for an host code address must not only
ignore Deleted entries, but must also ignore an entry
found via a host_extent element which is for a Deleted
entry that was re-used afterwards (pointed to by a
newer host_extent element).
Multiple solutions are possible for fixing the bug:
Sol1: cleanup the host_extents array when an entry is deleted.
The cleanup is however deemed costly:
Each invalidate operation must do a search in the host_extents.
The host_extents array must then be "compacted" to remove
the "dead" host extent element from the array.
The compact operation can be avoided if instead of removing
the element, one marks instead the element as "dead"
e.g. by using one bit of UInt len for that:
UInt len : 31;
Bool dead : 1;
This avoids the compact, but still incurrs the cost of
search and modify the host_extent for each entry invalidated.
Invalidating entries seems to be a critical operation
(e.g. specific ECLASS related data structures have been
done to allow fast deletion).
=> it is deemed that a solution not incurring cost during
invaliation is preferrable.
* Sol 2: detect in find_TTEntry_from_hcode
that the host_extent element is re-used, and handle it similarly
to an host_extents which points at a Deleted entry.
This detection is possible as if an entry is re-used after
having been deleted, this implies that its host code will be
after the end of the host code of the deleted entry
(as host code of a sector is not re-used).
The attached patch implements this solution.
* Sol 3: avoid re-using an entry : the entry would then stay
in Deleted state. This is deemed not ok as it would
imply that invalidation of entries will cause a sector to
become full faster.
The patch:
* adds a new function
Bool HostExtent__is_dead (const HostExtent* hx, const Sector* sec)
telling if the host extent hx from sector sec is a dead entry.
* this function is used in find_TTEntry_from_hcode so that
dead host extents are not resulting in host code to be found.
* adds a regression test which caused the assert failure before
(bug was found/reported/isolated in a small test case by Dejan Jevtic).
* To check the logic of HostExtent__is_dead, m_transtab.c sanity check is
completed to verify that the nr of entries in use in a sector is equal
to the nr of non dead entries in the host extent array.
* adds/improves traces in m_transtab.c (enabled at compile
time using #define DEBUG_TRANSTAB).
Some already existing 'if (0)' conditions are replaced
by if (DEBUG_TRANSTAB)
Regression tested on
f12/x86
debian6/amd64 (also with export EXTRA_REGTEST_OPTS=--sanity-level=4)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13290
(useful to check the sanity of valgrind on request and/or from GDB,
when an error is reported by the tool).
Also re-order the NEWS entries to put the internals things after
the user level new functions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13262
In a big applications, some recursive algorithms have created
hundreds of thousands of stacktraces, taking a lot of memory.
Option --merge-recursive-frames=<number> tells Valgrind to
detect and merge (collapse) recursive calls when recording stack traces.
The value is changeable using the monitor command
'v.set merge-recursive-frames'.
Also, this provides a new client request: VALGRIND_MONITOR_COMMAND
allowing to execute a gdbsrv monitor command from the client
program.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13246
The option --keep-stacktraces controls which stack trace(s) to keep for
malloc'd and/or free'd blocks. This can be used to obtain more information
for 'use after free' errors or to decrease Valgrind memory and/or cpu usage
by recording less information for heap blocks.
This fixes 312913 Dangling pointers error should also report the alloc
stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13223
information about the stack traces recorded by Valgrind.
This can be used to analyse one possible cause of Valgrind high
memory usage for some programs.
At work, a big set of regression tests crashed out of memory under Valgrind.
Two main causes for out of memory were identified:
1. big memory usage for stacktrace (exe contexts) recording by Valgrind
2. big number of partially initialised bytes.
This patch adds a gdbsrv monitor command that output (very) detailed
information about all the recorded exe context.
This has been used to analyse the problem 1. above,
showing the following identified causes for a (too) big nr of execontexts:
A. When the JIT handles an unknown SP update, even when --track-origins=no,
an execontext is (uselessly) created and recorded
to track the (never used) origin of some uninitialised stack memory.
This creates a whole bunch of 'one IP' execontexts.
B. same problem in handling some system calls (at least the brk system
calls always records an origin, even when --track-origins=yes).
C. The Valgrind unwinder cannot properly unwind some stack traces.
It unwinds a few frames, then go bezerk and stops at a "random" IP.
This then causes the same "logical" stacktrace to be truncated
and records thousands of times with this "differentiating" last IP.
For problem cause 2 above ( a lot of partially initialised bytes),
the idea is to similarly add another gdbsrv commands that will output
statistics about which stack traces are causing a lot of uninitialised bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13220
284540 Memcheck shouldn't count suppressions matching still-reachable allocations
307465 --show-possibly-lost=no should bring down the error count / exit code
Using the options --show-leak-kinds=kind1,kind2,.. and
--errors-for-leak-kinds=kind1,kind2,.., each leak kind (definite, indirect,
possible, reachable) can now be individually reported and/or counted as
an error.
In a leak suppression entry, an optional line 'match-leak-kinds:'
controls which leak kinds are suppressed by this entry.
This is a.o. useful to avoid definite leaks being "catched"
by a suppression entry aimed at suppressing possibly lost blocks.
Default behaviour is the same as 3.8.1
Old args (--show-reachable and --show-possibly-lost) are still accepted.
Addition of a new test (memcheck/tests/lks) testing the new args
and the new suppression line.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13170
This patch changes the way static variables are
recorded by readdwarf3.c (when giving --read-var-info=yes),
improving the way such variables are described.
Currently:
A static variable does not have the DW_AT_external tag.
So, readdwarf3.c does not consider it a global variable.
It is rather considered a "local" variable.
When it is recorded, it is associated to a range of program counters
(the functions in the file where it is visible).
However, even if the static variable is only visible
in the source file where it is declared, it can in reality
be used by any range of program counters, typically
by having the address of the local variable passed
to other functions.
Such local variable can then only be described
when the program counter is in the range of program
counters for which it has been recorded.
However, this (local) description is obtained
by a kludge in debuginfo.c (around line 3285).
This kludge then produces a strange description,
telling that the variable has been declared in
frame 0 of a thread (see second example below).
The kludge is not always able to describe
the address (if the IP of the tid is in another file than
where the variable has been declared).
I suspect the kludge can sometimes describe the var as being
declared in an unrelated thread
(e.g. if an error is triggered by tid 5, but tid1 is by
luck in an IP corresponding to the recorded range).
The patch changes the way a static variable is recorded:
if DW_AT_external tag is found, a variable is marked as global.
If a variable is not external, but is seen when level is 1,
then we record the variable as a global variable (i.e.
with a full IP range).
This improves the way such static variable are described:
* they are described even if being accessed by other files.
* their description is not in an artificial "thread frame".
First example:
**************
a variable cannot be described because it is
accessed by a function in another file:
with the trunk:
==20410== ----------------------------------------------------------------
==20410==
==20410== Possible data race during read of size 4 at 0x600F54 by thread #1
==20410== Locks held: none
==20410== at 0x4007E4: a (abc.c:42)
==20410== by 0x4006BC: main (mabc.c:24)
==20410==
==20410== This conflicts with a previous write of size 4 by thread #2
==20410== Locks held: none
==20410== at 0x4007ED: a (abc.c:42)
==20410== by 0x400651: brussels_fn (mabc.c:9)
==20410== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==20410== by 0x4E348C9: start_thread (pthread_create.c:300)
==20410==
==20410== ----------------------------------------------------------------
with the patch:
==4515== ----------------------------------------------------------------
==4515==
==4515== Possible data race during read of size 4 at 0x600F54 by thread #1
==4515== Locks held: none
==4515== at 0x4007E4: a (abc.c:42)
==4515== by 0x4006BC: main (mabc.c:24)
==4515==
==4515== This conflicts with a previous write of size 4 by thread #2
==4515== Locks held: none
==4515== at 0x4007ED: a (abc.c:42)
==4515== by 0x400651: brussels_fn (mabc.c:9)
==4515== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==4515== by 0x4E348C9: start_thread (pthread_create.c:300)
==4515==
==4515== Location 0x600f54 is 0 bytes inside global var "static_global"
==4515== declared at mabc.c:4
==4515==
==4515== ----------------------------------------------------------------
Second example:
***************
When the kludge can describe the variable, it is strangely described
as being declared in a frame of a thread, while for sure the declaration
has nothing to do with a thread
With the trunk:
==20410== Location 0x600f68 is 0 bytes inside local var "static_global_a"
==20410== declared at abc.c:3, in frame #0 of thread 1
With the patch:
==4515== Location 0x600f68 is 0 bytes inside global var "static_global_a"
==4515== declared at abc.c:3
#include <stdio.h>
static int static_global_a = 0; //// <<<< this is abc.c:3
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13153
Depending on the semctl command (arg3), arg4 might or might not be needed.
The PRE(sys_ipc) multiplexed syscall for semctl was always checking
all 4 args.
The fix consists in dereferencing the 4th arg (which in sys_ipc is ARG5)
only if the semctl syscall cmd implies 4 arguments.
This avoids the false positive on linux x86.
Note that PRE(sys_ipc) is still too simplistic as it assumes
that 6 args are always read, which is not the case.
This seems to cause false positive on mips:
memcheck on none/tests/sem gives:
Syscall param ipc(fifth) contains uninitialised byte(s)
It would be nice to implement the multiplexed PRE(sys_ipc) by
calling the PRE(sys_xxxx) similar PRE, depending on ARG1 of sys_ipc.
This would then avoid the simplistic PRE(sys_ipc) logic without duplicating
the logic in PRE(sys_semctl) (and all other sys_ipc multiplexed syscalls).
However, I found no easy way to do that.
With the current fix, some logic about semctl is partially duplicated between
the PRE(sys_ipc) (for platforms such as x86 having a multiplexed sys call)
and PRE(sys_semctl) (for platforms such as amd64, having a direct sys call)
to fix the false positive encountered on x86.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13082
In case of out of memory, Valgrind will output
the state of the address space manager and of the arena.
Then it will output a message to inform the user about the out of memory.
In case out of memory happens again while outputting the aspacemgr
or arena info, then another trial is done to only output the user msg.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13077
(allows to have the list of opened fds and the associated info
on request from GDB or from the shell, using vgdb)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13072
patch from Mark Wielaard.
(with small modifications).
Also clarified some comments related to the resume reply.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13052
For example, options below are silently "accepted"+ignored:
valgrind --profile-heaps=yes --max-stackframes=35 memcheck/tests/trivialleak
valgrind --profile-heaps=oui --max-stackframes=3.141592654 memcheck/tests/trivialleak
Also fixed the on-line --help output for option --core-redzone-size
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13037
Massif does not accept to take snapshots of heap before execution has started.
So, if such a snapshot is requested (using vgdb and option --vgdb-error=0),
then such a snapshot must be refused rather than causing an assert.
(problem reported by dark_footix@yahoo.fr)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13015
With some glibc version (e.g. on fedora 16), gdb output contains
a line with T_PSEUDO which should be filtered out.
Patch from Mark Wielaard.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13013
e.g. ccache gcc whatever... This fixes bugzilla #252955.
Patch from Stephen McCamant <smcc@CS.Berkeley.EDU>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12977
an immediate constant as the shift amount. This is needed for
powerpc Iop_ShlD64 etc. What it basically means that we do not
iterate over the bits in the 2nd operand because there are no
V-bits to set. An immediate constant is always completely defined.
Fixes bugzilla #305948.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12969
Testcase, vbit tester update, memcheck support for the new IROps,
NEWS announcement and opcode list update.
Patch by Christian Borntraeger (borntraeger@de.ibm.com).
Vbit tester tweaks by myself.
Fixes bugzilla #274695.
See also companion patch VEX r2496.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12921
