After the thread is detached not all thread memory is freed. This memory (dtv-dynamic thread vector)
can be used by the main thread. There are two types of run-time handling of TLS.
Difference is in the position of memory. It can be either before the thread pointer or
after the thread pointer.
Taken form the document http://www.akkadia.org/drepper/tls.pdf:
"Variant I for the thread-local storage data structures were developed
as part of the IA-64 ABI. Being brand-new, compatibility was no issue. The thread
register for thread t is denoted by tpt. It points to a Thread Control Block (TCB) which
contains at offset zero a pointer to the dynamic thread vector dtvt for the thread.
Variant II has a similar structure. The only difference is that the thread pointer
points to a Thread Control Block of unspecified size and content. Somewhere the TCB
contains a pointer to the dynamic thread vector but it is not specified where. This is
under control of the run-time environment and the pointer must not be assumed to be
directly accessible; compilers are not allowed to emit code which directly access the
dtvt."
Because of this we have two types of error when the program ends:
possibly lost, and definitely lost.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13761
* addition of VG_(needs_print_stats) in pub_tool_tooliface.h
* use the above in memcheck and helgrind
* output valgrind stats and calls print_stats in server.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13760
Iop_GetMSBs8x16, since the presence of those usually implies PMOVMSKB
instructions in the block, which can mean "inlined string operations".
Reduces the noise level a lot in some icc12 -O2 generated sequences.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13757
r13682 Initial cut at 3.9.0 release notes.
r13683 Remove duplicate NEWS entries for 3.9.0.
r13689 Minor docs/NEWS fixes
r13690 Documentation updates for 3.9.0.
r13691 More documentation updates, re leak-checker changes
r13692 NEWS: Note increased max mem size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13724
Move memcheck/mc_replace_strmem.c to shared/vg_replace_strmem.c and
add several intercepts for SSE-variants. Include that source file from
drd/drd_strmem_intercepts.c, helgrind/hg_intercepts.c and
memcheck/mc_replace_strmem.c.
Merge memcheck/tests/filter_memcpy into tests/filter_stderr_basic.
Update tests/check_headers_and_includes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13719
This change reduces the time needed to run the memcheck regression tests
with 2% on my development system.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13716
only reachable via other thread live register
The exiting thread will have its registers considered as not reachable
anymore, registers of other threads will be considered reachable.
This is ensured by using a different exit reason for the
exiting thread and for the other threads.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13670
vaddcuq, vadduqm, vaddecuq, vaddeuqm,
vsubcuq, vsubuqm, vsubecuq, vsubeuqm,
vbpermq and vgbbd.
The completes adding the Power ISA 2.07 support.
Bugzilla 325816
VEX commit id 2790
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13653
Option -v outputs a list of used suppressions. This only gives
the nr of times a suppression was used.
For a leak search, this only gives the nr of loss records that
have been suppressed, but it does not give additional needed details
to understand more precisely what has been suppressed
(i.e. nr of blocks and nr of bytes).
=> Add in the tool interface update_extra_suppression_use and
print_extra_suppression_info functions to allow the tool to record
additioonal use statistics for a suppression. These statistics
can be done depending on the error (and its data) which is suppressed.
Use this in memcheck for the leak suppressions, to maintain and output
the nr of blocks and bytes suppressed by a suppression during
the last leak search.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13651
On s390, the linux kernel does not deliver the exact address that
caused a SEGV but rather this address rounded down to a page boundary.
Also, old kernels do not deliver the address that caused a SIGBUS,
but deliver 0.
So, on s390, handle SIGSEGV and SIGBUG by always skipping one page
starting from the current value of the ptr scanning position.
As we need a correct value of ptr on this platform in the longjmp-ed
code, ptr is marked as volatile.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13648
This commit adds the testcases for the following instructions:
vpmsumb, vpmsumh, vpmsumw, vpmsumd, vpermxor, vcipher, vcipherlast,
vncipher, vncipherlast, vsbox,
vclzb, vclzw, vclzh, vclzd,
vpopcntb, vpopcnth, vpopcntw, vpopcntd,
vnand, vorc, veqv,
vshasigmaw, vshasigmad,
bcdadd, bcdsub
The VEX commit that added the support for the above instructions was
commit 2789.
The patch is for Bugzilla 325628
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13646
* initialise leak_check heuristic parameter in the leak_check monitor command
* show the default value (none heuristic) in the monitor help command
(none value chosen as default as this gives a backward compatible
behaviour).
* document the heuristic leak check parameter in memcheck manual
monitor command section
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13631
The fault catcher installed during leak scan to catter e.g. for
possible desynchronisation between real protection and aspacemgr
was not activated when the scanned ptr was directly pointing in
a desynchronised page.
This was (initially only) visible on ppc32 (gcc110) as the page size of
gcc110 is big (64 K).
=> modified the leak-segv-jmp test so as to produce the problem also
on systems with smaller pages.
The fix consists in calling the setjmp before the scan loop,
and skip the bad address which has been recorded by the fault
catcher.
Also, deemed better to just skip one single Addr rather than a full page
(e.g. to skip less data in case some addresses are unreadable e.g.
on strange hardware).
Performance of the leak scan has been measured, seems slightly
faster on x86,amd64 and ppc32. Slightly slower on ppc64.
Also if verbose argument is given, outputs the nr of bytes skipped
due to fault.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13623
* Remove dead code in m_oset.c VG_(OSetGen_ResetIterAt)
The code at the end of VG_(OSetGen_ResetIterAt) was unreachable
(detected by BEAM checker).
Looking at SVN, the initial commit of VG_(OSetGen_ResetIterAt)
already contained this deadcode.
* pub_tool_oset.h was wrongly indicating that signed words could
be used for fast cmp oset.
* modified memcheck/tests/unit_oset.c to test VG_(OSetGen_ResetIterAt)
* modified memcheck/tests/unit_oset.c to not use signed words
(it was previously using signed words, but only with positive values)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13622
With the change, the test compiles on ppc32.
However, the test fails miserably with
Segmentation fault
while the whole purpose of the test was to see the leak search
would *not* segfault.
More investigations needed, but still committing as is to let
the tests compile and run.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13612
* fix the assert
* some better comments
* update test to verify who_points_at behaviour with an interiorly pointed block
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13609
This patch adds testcases to an existing testcase
source file to test the new instructions which were
added to VEX support in the phase 3 ISA 2.07 code patch.
The patch also makes a small change to memcheck's
vbit tester code to allow successful execution.
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Bugzilla 324894. Corresponding VEX commit 2779
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13594
Depending on the compiler or optimisation level, the blocks that
are supposed to be possibly leaked are still reachable.
=> change the pointers to be global variables,
and do the allocation in a function, not in main.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13591
The option --leak-check-heuristics=heur1,heur2,... can activate
various heuristics to decrease the number of false positive
"possible leaks" for C++ code. The available heuristics are
detecting valid interior pointers to std::stdstring, to new[] allocated
arrays with elements having destructors and to interior pointers pointing
to an inner part of a C++ object using multiple inheritance.
This fixes 280271 Valgrind reports possible memory leaks on still-reachable
std::string
This has been tested on x86/amd64/ppc32/ppc64.
First performance measurements seems to show a neglectible impact on
the leak search.
More feedback welcome both on performance and functional aspects
(false positive 'possibly leaked' rate decrease and/or
false negative 'possibly leaked' rate increase).
Note that the heuristic is not checking that the memory has been
allocated with "new" or "new[]", as it is expected that in some cases,
specific alloc fn are used for c++ objects instead of the standard new/new[].
If needed, we might add an option to check the alloc functions
to be new/new[].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13582
(1) Detect availability of pthread_setname_np. Ignore testcases
memcheck/tests/threadname[_xml] if not available.
(2) Enable _GNU_SOURCE to avold compiler warnings.
(3) In threadname_xml filter out stackframes referring to system
libraries. Added tests/filter_xml_frames to do that.
(4) Adjust .exp files as needed
(5) Do not ship stdout.exp for memcheck/tests/threadname[_xml].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13557
can be used in error messages. That should be helpful when debugging
multithreaded applications.
Patch by Matthias Schwarzott <zzam@gentoo.org> with some minor
modifications. Fixes BZ 322254.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13553
to put a "marker" msg in process log output
* v.info n_errs_found accepts optional msg, added in the output of
the monitor command.
* use VG_(printf) rather than VG_(gdb_printf) when output of command
should be redirected according to v.set gdb_output|log_output|mixed_output
* also avoid calling gdb_printf in output sink processing
to output zero bytes, as gdb_printf expects to have a null terminated
string, which is not ensured when 0 bytes have to be output.
* some minor reformatting (replace char* xxx by char *xxx).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13532
