| ed39800a83baf5bffbe391f3974eb2af0f415f80 |
|
21-Jun-2017 |
Elliott Hughes <enh@google.com> |
Upgrade to valgrind 3.13.0 (15 June 2017).
Release 3.13.0 (15 June 2017)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.13.0 is a feature release with many improvements and the usual collection of
bug fixes.
This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12.
* ==================== CORE CHANGES ===================
* The translation cache size has been increased to keep up with the demands of
large applications. The maximum number of sectors has increased from 24 to
48. The default number of sectors has increased from 16 to 32 on all
targets except Android, where the increase is from 6 to 12.
* The amount of memory that Valgrind can use has been increased from 64GB to
128GB. In particular this means your application can allocate up to about
60GB when running on Memcheck.
* Valgrind's default load address has been changed from 0x3800'0000 to
0x5800'0000, so as to make it possible to load larger executables. This
should make it possible to load executables of size at least 1200MB.
* A massive spaceleak caused by reading compressed debuginfo files has been
fixed. Valgrind should now be entirely usable with gcc-7.0 "-gz" created
debuginfo.
* The C++ demangler has been updated.
* Support for demangling Rust symbols has been added.
* A new representation of stack traces, the "XTree", has been added. An XTree
is a tree of stacktraces with data associated with the stacktraces. This is
used by various tools (Memcheck, Helgrind, Massif) to report on the heap
consumption of your program. Reporting is controlled by the new options
--xtree-memory=none|allocs|full and --xtree-memory-file=<file>.
A report can also be produced on demand using the gdbserver monitor command
'xtmemory [<filename>]>'. The XTree can be output in 2 formats: 'callgrind
format' and 'massif format. The existing visualisers for these formats (e.g.
callgrind_annotate, KCachegrind, ms_print) can be used to visualise and
analyse these reports.
Memcheck can also produce XTree leak reports using the Callgrind file
format. For more details, see the user manual.
* ================== PLATFORM CHANGES =================
* ppc64: support for ISA 3.0B and various fixes for existing 3.0 support
* amd64: fixes for JIT failure problems on long AVX2 code blocks
* amd64 and x86: support for CET prefixes has been added
* arm32: a few missing ARMv8 instructions have been implemented
* arm64, mips64, mips32: an alternative implementation of Load-Linked and
Store-Conditional instructions has been added. This is to deal with
processor implementations that implement the LL/SC specifications strictly
and as a result cause Valgrind to hang in certain situations. The
alternative implementation is automatically enabled at startup, as required.
You can use the option --sim-hints=fallback-llsc to force-enable it if you
want.
* Support for OSX 10.12 has been improved.
* On Linux, clone handling has been improved to honour CLONE_VFORK that
involves a child stack. Note however that CLONE_VFORK | CLONE_VM is handled
like CLONE_VFORK (by removing CLONE_VM), so applications that depend on
CLONE_VM exact semantics will (still) not work.
* The TileGX/Linux port has been removed because it appears to be both unused
and unsupported.
* ==================== TOOL CHANGES ====================
* Memcheck:
- Memcheck should give fewer false positives when running optimised
Clang/LLVM generated code.
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
to produce the end of execution leak report in a xtree callgrind format
file.
- New option 'xtleak' in the memcheck leak_check monitor command, to produce
the leak report in an xtree file.
* Massif:
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- For some workloads (typically, for big applications), Massif memory
consumption and CPU consumption has decreased significantly.
* Helgrind:
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN, useful
for Ada gnat compiled applications.
* ==================== OTHER CHANGES ====================
* For Valgrind developers: in an outer/inner setup, the outer Valgrind will
append the inner guest stacktrace to the inner host stacktrace. This helps
to investigate the errors reported by the outer, when they are caused by the
inner guest program (such as an inner regtest). See README_DEVELOPERS for
more info.
* To allow fast detection of callgrind files by desktop environments and file
managers, the format was extended to have an optional first line that
uniquely identifies the format ("# callgrind format"). Callgrind creates
this line now, as does the new xtree functionality.
* File name template arguments (such as --log-file, --xtree-memory-file, ...)
have a new %n format letter that is replaced by a sequence number.
* "--version -v" now shows the SVN revision numbers from which Valgrind was
built.
* ==================== FIXED BUGS ====================
The following bugs have been fixed or resolved. Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry. We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.
To see details of a given bug, visit
https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.
162848 --log-file output isn't split when a program forks
340777 Illegal instruction on mips (ar71xx)
341481 MIPS64: Iop_CmpNE32 triggers false warning on MIPS64 platforms
342040 Valgrind mishandles clone with CLONE_VFORK | CLONE_VM that clones
to a different stack.
344139 x86 stack-seg overrides, needed by the Wine people
344524 store conditional of guest applications always fail - observed on
Octeon3(MIPS)
348616 Wine/valgrind: noted but unhandled ioctl 0x5390 [..] (DVD_READ_STRUCT)
352395 Please provide SVN revision info in --version -v
352767 Wine/valgrind: noted but unhandled ioctl 0x5307 [..] (CDROMSTOP)
356374 Assertion 'DRD_(g_threadinfo)[tid].pt_threadid !=
INVALID_POSIX_THREADID' failed
358213 helgrind/drd bar_bad testcase hangs or crashes with new glibc pthread
barrier implementation
358697 valgrind.h: Some code remains even when defining NVALGRIND
359202 Add musl libc configure/compile
360415 amd64 instructions ADCX and ADOX are not implemented in VEX
== 372828 (vex amd64->IR: 0x66 0xF 0x3A 0x62 0x4A 0x10)
360429 unhandled ioctl 0x530d with no size/direction hints (CDROMREADMODE1)
362223 assertion failed when .valgrindrc is a directory instead of a file
367543 bt/btc/btr/bts x86/x86_64 instructions are poorly-handled wrt flags
367942 Segfault vgPlain_do_sys_sigaction (m_signals.c:1138)
368507 can't malloc chunks larger than about 34GB
368529 Android arm target link error, missing atexit and pthread_atfork
368863 WARNING: unhandled arm64-linux syscall: 100 (get_robust_list)
368865 WARNING: unhandled arm64-linux syscall: 272 (kcmp)
368868 disInstr(arm64): unhandled instruction 0xD53BE000 = cntfrq_el0 (ARMv8)
368917 WARNING: unhandled arm64-linux syscall: 218 (request_key)
368918 WARNING: unhandled arm64-linux syscall: 127 (sched_rr_get_interval)
368922 WARNING: unhandled arm64-linux syscall: 161 (sethostname)
368924 WARNING: unhandled arm64-linux syscall: 84 (sync_file_range)
368925 WARNING: unhandled arm64-linux syscall: 130 (tkill)
368926 WARNING: unhandled arm64-linux syscall: 97 (unshare)
369459 valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
370028 Reduce the number of compiler warnings on MIPS platforms
370635 arm64 missing syscall getcpu
371225 Fix order of timer_{gettime,getoverrun,settime} syscalls on arm64
371227 Clean AArch64 syscall table
371412 Rename wrap_sys_shmat to sys_shmat like other wrappers
371471 Valgrind complains about non legit memory leaks on placement new (C++)
371491 handleAddrOverrides() is [incorrect] when ASO prefix is used
371503 disInstr(arm64): unhandled instruction 0xF89F0000
371869 support '%' in symbol Z-encoding
371916 execution tree xtree concept
372120 c++ demangler demangles symbols which are not c++
372185 Support of valgrind on ARMv8 with 32 bit executable
372188 vex amd64->IR: 0x66 0xF 0x3A 0x62 0x4A 0x10 0x10 0x48 (PCMPxSTRx $0x10)
372195 Power PC, xxsel instruction is not always recognized.
372504 Hanging on exit_group
372600 process loops forever when fatal signals are arriving quickly
372794 LibVEX (arm32 front end): 'Assertion szBlg2 <= 3' failed
373046 Stacks registered by core are never deregistered
373069 memcheck/tests/leak_cpp_interior fails with GCC 5.1+
373086 Implement additional Xen hypercalls
373192 Calling posix_spawn in glibc 2.24 completely broken
373488 Support for fanotify API on ARM64 architecture
== 368864 WARNING: unhandled arm64-linux syscall: 262 (fanotify_init)
373555 Rename BBPTR to GSPTR as it denotes guest state pointer only
373938 const IRExpr arguments for matchIRExpr()
374719 some spelling fixes
374963 increase valgrind's load address to prevent mmap failure
375514 valgrind_get_tls_addr() does not work in case of static TLS
375772 +1 error in get_elf_symbol_info() when computing value of 'hi' address
for ML_(find_rx_mapping)()
375806 Test helgrind/tests/tc22_exit_w_lock fails with glibc 2.24
375839 Temporary storage exhausted, with long sequence of vfmadd231ps insns
== 377159 "vex: the `impossible' happened" still present
== 375150 Assertion 'tres.status == VexTransOK' failed
== 378068 valgrind crashes on AVX2 function in FFmpeg
376142 Segfaults on MIPS Cavium Octeon boards
376279 disInstr(arm64): unhandled instruction 0xD50320FF
376455 Solaris: unhandled syscall lgrpsys(180)
376518 Solaris: unhandled fast trap getlgrp(6)
376611 ppc64 and arm64 don't know about prlimit64 syscall
376729 PPC64, remove R2 from the clobber list
== 371668
376956 syswrap of SNDDRV and DRM_IOCTL_VERSION causing some addresses
to be wrongly marked as addressable
377066 Some Valgrind unit tests fail to compile on Ubuntu 16.10 with
PIE enabled by default
377376 memcheck/tests/linux/getregset fails with glibc2.24
377427 PPC64, lxv instruction failing on odd destination register
377478 PPC64: ISA 3.0 setup fixes
377698 Missing memory check for futex() uaddr arg for FUTEX_WAKE
and FUTEX_WAKE_BITSET, check only 4 args for FUTEX_WAKE_BITSET,
and 2 args for FUTEX_TRYLOCK_PI
377717 Fix massive space leak when reading compressed debuginfo sections
377891 Update Xen 4.6 domctl wrappers
377930 fcntl syscall wrapper is missing flock structure check
378524 libvexmultiarch_test regression on s390x and ppc64
378535 Valgrind reports INTERNAL ERROR in execve syscall wrapper
378673 Update libiberty demangler
378931 Add ISA 3.0B additional isnstructions, add OV32, CA32 setting support
379039 syscall wrapper for prctl(PR_SET_NAME) must not check more than 16 bytes
379094 Valgrind reports INTERNAL ERROR in rt_sigsuspend syscall wrapper
379371 UNKNOWN task message [id 3444, to mach_task_self(), reply 0x603]
(task_register_dyld_image_infos)
379372 UNKNOWN task message [id 3447, to mach_task_self(), reply 0x603]
(task_register_dyld_shared_cache_image_info)
379390 unhandled syscall: mach:70 (host_create_mach_voucher_trap)
379473 MIPS: add support for rdhwr cycle counter register
379504 remove TileGX/Linux port
379525 Support more x86 nop opcodes
379838 disAMode(x86): not an addr!
379703 PC ISA 3.0 fixes: stxvx, stxv, xscmpexpdp instructions
379890 arm: unhandled instruction: 0xEBAD 0x1B05 (sub.w fp, sp, r5, lsl #4)
379895 clock_gettime does not execute POST syscall wrapper
379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966 WARNING: unhandled amd64-linux syscall: 313 (finit_module)
380200 xtree generated callgrind files refer to files without directory name
380202 Assertion failure for cache line size (cls == 64) on aarch64.
380397 s390x: __GI_strcspn() replacement needed
n-i-bz Fix pub_tool_basics.h build issue with g++ 4.4.7.
(3.13.0.RC1: 2 June 2017, vex r3386, valgrind r16434)
(3.13.0.RC2: 9 June 2017, vex r3389, valgrind r16443)
(3.13.0: 14 June 2017, vex r3396, valgrind r16446)
Bug: N/A
Test: manual
Change-Id: Id4498a49f462c3689cbcb35c15f96a8c7e3cea17
/external/valgrind/helgrind/libhb_core.c
|
| b3a1e4bffbdbbf38304f216af405009868f43628 |
|
21-Aug-2015 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update copyright dates, to include 2015. No functional change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15577 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 5e5cb009574352880f1bc530e1a73ddaae5003fc |
|
03-Aug-2015 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix printf format inconsistencies as pointed out by gcc -Wformat-signedness.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15480 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| ad4e979f408239dabbaae955d8ffcb84a51a5c85 |
|
05-Jul-2015 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix typos in source code. Patch by Dmitriy (olshevskiy87@bk.ru).
Fixes BZ #349874
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15394 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 3a085bf78a78ddddbe4b237da3d200ca502fe51e |
|
26-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Make some numbers in helgrind stats use , separators, as the numbers can be big
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15294 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 328d6627c26471332610da3f5a0b9cc3cdd410c7 |
|
25-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch decreases significantly the memory needed for OldRef and
slightly increases the performance. It also moderately improves
the nr of cases where helgrind can provide the stack trace of the old
access (when using the same amount of memory for the OldRef entries).
The patch also provides a new helgrind monitor command to show
the recorded accesses for an address+len, and adds an optional argument
lock_address to the monitor command 'info locks', to show the info
about just this lock.
Currently, oldref are maintained in a sparse WA, that points to N
entries, as specified by --conflict-cache-size=N.
For each entry (associated to an address), we have the last 5 accesses.
Old entries are recycled in an exact LRU order.
But inside an entry, we could have a recent access, and 4 very
old accesses that are kept 'alive' by a single thread accessing
repetitively the address shared with the 4 other old entries.
The attached patch replaces the sparse WA that maintains the OldREf
by an hash table.
Each OldRef now also only maintains one single access for an address.
As an OldRef now maintains only one access, all the entries are now
strictly in LRU mode.
Memory used for OldRef
-----------------------
For the trunk, an OldRef has a size of 72 bytes (on 32 bits archs)
maintaining up to 5 accesses to the same address.
On 64 bits arch, an OldRef is 104 bytes.
With the patch, an OldRef has a size of 32 bytes (on 32 bits archs)
or 56 bytes (on 64 bits archs).
So, for one single access, the new code needs (on 32 bits)
32 bytes, while the trunk needs only 14.4 bytes.
However, that is the worst case, assuming that the 5 entries in the
accs array are all used.
Looking on 2 big apps (one of them being firefox), we see that
we have very few OldRef entries that have the 5 entries occupied.
On a firefox startup, of the 5x1,000,000 accesses, we only have
1,406,939 accesses that are used.
So, in average, the trunk uses in reality around 52 bytes per access.
The default value for --conflict-cache-size has been doubled to 2000000.
This ensures that the memory used for the OldRef is more or less the
same as the trunk (104Mb for OldRef entries).
Memory used for sparseWA versus hashtable
-----------------------------------------
Looking on 2 big apps (one of them being firefox), we see that
there are big variations on the size of the WA : it can go in a few
seconds from 10MB to 250MB, or can decrease back to 10 MB.
This all depends where the last N accesses were done: if well localised,
the WA will be small.
If the last N accesses were distributed over a big address space,
then the WA will be big: the last level of WA (the biggest memory consumer)
uses slightly more than 1KB (2KB on 64 bits) for each '256 bytes' memory
zone where there is an oldref. So, in the worst case, on 32 bits, we
need > 1_000_000_000 sparseWA memory to keep 1_000_000 OldRef.
The hash table has between 1 to 2 Word overhead per OldRef
(as the chain array is +- doubled each time the hash table is full).
So, unless the OldRef are extremely localised, the overhead of the
hash table will be significantly less.
With the patch, the core arena total alloc is:
5299535/1201448632 totalloc-blocks/bytes
The trunk is
6693111/3959050280 totalloc-blocks/bytes
(so, around 1.20Gb versus 3.95Gb).
This big difference is due to the fact that the sparseWA repetitively
allocates then frees Level0 or LevelN when OldRef in the region covered
by the Level0/N have all been recycled.
In terms of CPU
---------------
With the patch, on amd64, a firefox startup seems slightly faster (around 1%).
The peak memory mmaped/used decreases by 200Mb.
For a libreoffice test, the memory decreases by 230Mb. CPU also decreases
slightly (1%).
In terms of correctness:
-----------------------
The trunk could potentially show not the most recent access
to the memory of a race : the first OldRef entry matching the raced upon
address was used, while we could have a more recent access in a following
OldRef entry. In other words, the trunk only guaranteed to find the
most recent access in an OldRef, but not between the several OldRef that
could cover the raced upon address.
So, assuming it is important to show the most recent access, this patch
ensures we really show the most recent access, even in presence of overlapping
accesses.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15289 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| a4286b933eb6b3f091a77f0125df3071c153d3c7 |
|
23-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
helgrind stats: show the total nr of thr_n_rcec
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15285 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 1e798b0e596bd836ef93287add8401488c4fb824 |
|
23-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
helgrind stats: give the memory occupied by the OldRef
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15284 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| a4b20c089072bdaf83938044ec077a6a89622481 |
|
23-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add stats in helgrind for oldref history found versus not found
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15283 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 7ab06467ab27ed51b829a724e5c40cb0dc19d88d |
|
17-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Follow up to r15253:
Having a one elt free lineF cache avoids many PA calls.
This seems to slightly improve (a few %) a firefox startup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15254 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 71ed3c9382fa816a84731e9a2ddb9eda7d5624a6 |
|
17-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch reduces the memory needed for the linesF.
Currently, each SecMap has an array of linesF, referenced by the linesZ
of the secmap that needs a lineF, via an index stored in dict[1].
When the array is full, its size is doubled.
The linesF array of a secmap is freed when the SecMap is GC-ed.
The above strategy has the following consequences:
A. in average, 25% of the LinesF are unused.
B. if a SecMap has 'temporarily' a need for linesF, but afterwards,
these linesF are converted to normal lineZ representation, the linesF
will not be recuperated unless the SecMap is GC-ed (i.e. fully marked
no access).
The patch replaces the linesF array private per SecMap
by a pool allocator of LinesF shared between all SecMap.
A lineZ that needs a lineF will directly point to its lineF (using a pointer
stored in dict[1]), instead of having in dict[1] the index in the SecMap
linesF array.
When a lineZ needs a lineF, it is allocated from the pool allocator.
When a lineZ does not need anymore a lineF, it is returned back to the
pool allocator.
On a firefox startup, the above strategy reduces the memory for linesF
by about 42Mb. It seems that the more firefox is used (e.g. to visit
a few websites), the bigger the memory gain.
After opening the home page of valgrind, wikipedia and google, the memory
gain is about 94Mb:
trunk:
linesF: 392,181 allocd ( 203,934,120 bytes occupied) ( 173,279 used)
patch:
linesF: 212,966 allocd ( 109,038,592 bytes occupied) ( 170,252 used)
There is also less alloc/free operations in core arena with the patch:
trunk:
core : 810,680,320/ 802,291,712 max/curr mmap'd, 17/19 unsplit/split sb unmmap'd, 759,441,224/ 703,191,896 max/curr, 40631760/16376828248 totalloc-blocks/bytes, 188015696 searches 8 rzB
patch:
core : 701,628,416/ 690,753,536 max/curr mmap'd, 12/29 unsplit/split sb unmmap'd, 643,041,944/ 577,793,712 max/curr, 32050040/14056017712 totalloc-blocks/bytes, 174097728 searches 8 rzB
In terms of performance, no CPU impact detected on Firefox startup.
Note we have no representative reproducible (and preferrably small)
perf test that uses extensively linesF. Firefox is a good heavy lineF
user but is far to be reproducible, and is very far to be small.
Theoretically, in terms of CPU performance, the patch might have some
small benefits here and there for read operations, as the lineF pointer
is directly retrieved from the lineZ, rather than retrieved via an indirection
in the linesF array.
For write operations, the patch might need a little bit more CPU,
as we replace an
assignment to lineF inUse boolean to False (and then probably back to True
when the cacheline is written back)
by
a call to pool allocator VG_(freeEltPA) (and then probably a call to
VG_(allocEltPA) when the cacheline is written back).
These PA functions are small, so cost should be ok.
We might however still maintain in clear_LineF_of_Z the last cleared lineF
and re-use it in alloc_LineF_for_Z. Not sure how many calls to the PA functions
would be avoided by this '1 elt cache' (and the needed 'if elt == NULL'
check in both clear_LineF_of_Z and alloc_LineF_for_Z.
This possible optimisationwill be looked at later.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15253 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 0fb30ace7cd9e63623c4ed5dd720f18b0ea9dee3 |
|
15-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add statistics about the nr of used linesF
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15237 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| fc00a2a1f86ba77f905c8ee34b3c8c949bb9c107 |
|
15-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch (re-)gains performance in helgrind, following revision 15207, that
reduced memory use doing SecMap GC, but was slowing down some workloads
(typically, workloads doing a lot of malloc/free).
A significant part of the slowdown came from the clear of the filter,
that was not optimised for big ranges : the filter was working byte
per byte till an 8 alignment. Then working per 8 bytes at a time.
With the patch, the filter clear is done the following way:
* all the bytes till 8 alignement are done together
* then 8 bytes at a time till filter_line alignment (32 bytes)
* then 32 bytes at a time.
Moreover, as the filter cache is small (1024 lines of 32 bytes),
clearing filter for ranges bigger than 32Kb was uselessly checking
several times the same entry. This is now avoided by using a range
check rather than a tag equality check.
As the new filter clear is significanly more complex than the previous simple
algorithm, the old algorithm is kept and used to check the new algorithm
when CHECK_ZSM is defined as 1.
The patch also contains a few micro optimisations and
disables
// VG_(track_die_mem_stack) ( evh__die_mem );
as this had no effect and was somewhat costly.
With this patch, we have almost reached for all perf tests the same
performance as we had before revision 15207. Some tests are still
slightly slower than before the SecMap GC (max 2% difference).
Some tests are now significantly faster (e.g. sarp).
For almost all tests, we are now faster than valgrind 3.10.1.
Details below.
Regtested on x86/amd64/ppc64 (and regtested with all compile time
checks set).
I have also regtested with libreoffice and firefox.
(with firefox, also with CHECK_ZSM set to 1).
Details about performance:
hgtrace = this patch
trunk_untouched = trunk
base_secmap = trunk before secmap GC
valgrind 3.10.1 included for comparison
Measured on core i5 2.53GHz
-- Running tests in perf ----------------------------------------------
-- bigcode1 --
bigcode1 hgtrace :0.14s he: 2.6s (18.4x, -----)
bigcode1 trunk_untouched:0.14s he: 2.6s (18.4x, -0.4%)
bigcode1 base_secmap:0.14s he: 2.6s (18.6x, -1.2%)
bigcode1 valgrind-3.10.1:0.14s he: 2.8s (19.8x, -7.8%)
-- bigcode2 --
bigcode2 hgtrace :0.14s he: 6.3s (44.7x, -----)
bigcode2 trunk_untouched:0.14s he: 6.2s (44.6x, 0.2%)
bigcode2 base_secmap:0.14s he: 6.3s (45.0x, -0.6%)
bigcode2 valgrind-3.10.1:0.14s he: 6.6s (47.1x, -5.4%)
-- bz2 --
bz2 hgtrace :0.64s he:11.3s (17.7x, -----)
bz2 trunk_untouched:0.64s he:11.7s (18.2x, -3.2%)
bz2 base_secmap:0.64s he:11.1s (17.3x, 1.9%)
bz2 valgrind-3.10.1:0.64s he:12.6s (19.7x,-11.3%)
-- fbench --
fbench hgtrace :0.29s he: 3.4s (11.8x, -----)
fbench trunk_untouched:0.29s he: 3.4s (11.7x, 0.6%)
fbench base_secmap:0.29s he: 3.6s (12.4x, -5.0%)
fbench valgrind-3.10.1:0.29s he: 3.5s (12.2x, -3.5%)
-- ffbench --
ffbench hgtrace :0.26s he: 9.8s (37.7x, -----)
ffbench trunk_untouched:0.26s he:10.0s (38.4x, -1.9%)
ffbench base_secmap:0.26s he: 9.8s (37.8x, -0.2%)
ffbench valgrind-3.10.1:0.26s he:10.0s (38.4x, -1.9%)
-- heap --
heap hgtrace :0.11s he: 9.2s (84.0x, -----)
heap trunk_untouched:0.11s he: 9.6s (87.1x, -3.7%)
heap base_secmap:0.11s he: 9.0s (81.9x, 2.5%)
heap valgrind-3.10.1:0.11s he: 9.1s (82.9x, 1.3%)
-- heap_pdb4 --
heap_pdb4 hgtrace :0.13s he:10.7s (82.3x, -----)
heap_pdb4 trunk_untouched:0.13s he:11.0s (84.8x, -3.0%)
heap_pdb4 base_secmap:0.13s he:10.5s (80.8x, 1.8%)
heap_pdb4 valgrind-3.10.1:0.13s he:10.6s (81.8x, 0.7%)
-- many-loss-records --
many-loss-records hgtrace :0.01s he: 1.5s (152.0x, -----)
many-loss-records trunk_untouched:0.01s he: 1.6s (157.0x, -3.3%)
many-loss-records base_secmap:0.01s he: 1.6s (158.0x, -3.9%)
many-loss-records valgrind-3.10.1:0.01s he: 1.7s (167.0x, -9.9%)
-- many-xpts --
many-xpts hgtrace :0.03s he: 2.8s (91.7x, -----)
many-xpts trunk_untouched:0.03s he: 2.8s (94.7x, -3.3%)
many-xpts base_secmap:0.03s he: 2.8s (94.0x, -2.5%)
many-xpts valgrind-3.10.1:0.03s he: 2.9s (97.7x, -6.5%)
-- memrw --
memrw hgtrace :0.06s he: 7.3s (121.2x, -----)
memrw trunk_untouched:0.06s he: 7.2s (120.3x, 0.7%)
memrw base_secmap:0.06s he: 7.1s (117.7x, 2.9%)
memrw valgrind-3.10.1:0.06s he: 8.1s (135.2x,-11.6%)
-- sarp --
sarp hgtrace :0.02s he: 7.6s (378.5x, -----)
sarp trunk_untouched:0.02s he: 8.4s (422.0x,-11.5%)
sarp base_secmap:0.02s he: 8.6s (431.0x,-13.9%)
sarp valgrind-3.10.1:0.02s he: 8.8s (442.0x,-16.8%)
-- tinycc --
tinycc hgtrace :0.20s he:12.4s (62.0x, -----)
tinycc trunk_untouched:0.20s he:12.6s (63.2x, -1.9%)
tinycc base_secmap:0.20s he:12.6s (63.0x, -1.6%)
tinycc valgrind-3.10.1:0.20s he:12.7s (63.5x, -2.3%)
-- Finished tests in perf ----------------------------------------------
== 12 programs, 48 timings =================
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15236 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 364f0bb8262e132da1659b82571c6615d24d0c3f |
|
15-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
micro-opt: add an UNLIKELY
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15235 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 2bd2326e8361a752dfbd4eced9a61b6224f05272 |
|
11-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
VTS stats
* add the missing increment to the nr of gc done
* add vts pruning stat
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15214 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8939e0990ab7a7fcc81f67e7ce3573148e4e1c2c |
|
11-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Simplify shmem__invalidate_scache_range : it only has to handle
cacheline aligned ranges.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15213 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 1475a7ffc4f60e78d402ba2572f1624cebbbb76a |
|
11-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Small optimisations in libhb_core.c
* avoid indirection via function pointers to call SVal__rcinc and SVal__rcdec
* declare these functions inlined
* transform 2 asserts on hot path in conditionally compiled checks
on CHECK_ZSM
This slightly optimises some perf tests with helgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15212 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| f54cb66eba8137cac5b3ee8be29bb24c1ddfb535 |
|
11-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch decreases the memory used by the helgrind SecMap,
by implementing a Garbage Collection for the SecMap.
The basic change is that freed memory is marked as noaccess
(while before, it kept the previous marking, on the basis that
non buggy applications are not accessing freed memory in any case).
Keeping the previous marking avoids the CPU/memory changes needed
to mark noaccess.
However, marking freed memory noaccess and GC the secmap reduces
the memory on big apps.
For example, a firefox test needs 220Mb less (on about 2.06 Gb).
Similar reduction for libreoffice batch (260 MB less on 1.09 Gb).
On such applications, the performance with the patch is similar to the trunk.
There is a performance decrease for applications that are doing
a lot of malloc/free repetitively: e.g. on some perf tests, an increase
in cpu of up to 15% has been observed.
Several performance optimisations can be done afterwards to not loose
too much performance. The decrease of memory is expected to produce
in any case significant benefit in memory constrained environments
(e.g. android phones).
So, after discussion with Julian, it was decided to commit as-is
and (re-)gain (part of) performance in follow-up commits.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15207 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| a1ac2f4d9512ce19d63861226652d4d5e5f8955c |
|
01-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch reduces the memory needed for a VtsTE by 25% (one word)
on 32 bits platforms. No memory reduction on 64 bits platforms,
due to alignment.
The patch also shows the vts stats when showing the helgrind stats.
The perf/memrw.c perf test gets also some new additional features
allowing e.g. to control the size of the read or written blocks.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15174 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 47124e91145f71f6db7d0a60031fe49a6b6ea141 |
|
25-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Give statistics about RCEC helgrind hash table chains.
Improve statistic in coregrind hash table
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15141 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| d005b2ccaa44bd1e4633a806788ad387701b9e69 |
|
21-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add some stats to helgrind stats:
* nr of client malloc-ed blocks
* how many OldRef helgrind has, and the distribution
of these OldRef according to the nr of accs they have
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15128 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| e0829e01793448f888699d0ff928dac93c395c36 |
|
21-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Do RCEC_GC when approaching the max nr of RCEC, not when reaching it.
Otherwise, long running applications still see the max nr of RCEC
slowly growing, which increases the memory usage and
makes the (fixed) contextTab hash table slower to search.
Without this margin, the max could increase as the GC code
is not called at exactly the moment we reach the previous max,
but rather when a thread has run a bunch of basic blocks.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15126 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| cabdbb5cab3740c7082e44b770a582c8186888e9 |
|
20-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch changes the policy that does the GC of OldRef and RCEC
conflict cache size.
The current policy is:
A 'more or less' LRU policy is implemented by giving
to each OldRef a generation nr in which it was last touched.
A new generation is created every 50000 new access.
GC is done when the nr of OldRef reaches --conflict-cache-size.
The GC consists in removing enough generations to free
half of the entries.
After GC of OldRef, the RCEC (Ref Counted Exe Contexts)
not referenced anymore are GC-ed.
The new policy is:
An exact LRU policy is implemented using a doubly linked list
of OldRef.
When reaching --conflict-cache-size, the LRU entry is re-used.
The not referenced RCEC are GC-ed when less than 75% of the RCEC
are referenced, and the nr of RCEC is 'big' (at least half the
size of the contextTab, and at least the max nr of RCEC reached
previously).
(note: tried to directly recover a unref'ed RCEC when recovering
the LRU oldref, but that gives a lot of re-creation of RCEC).
new policy has the following advantages/disadvantages:
1. It is faster (at least for big applications)
On a firefox startup/exit, we gain about 1m30 second on 11m.
Similar 5..10% speed up encountered on other big applications
or on the new perf/memrw test.
The speed increase depends on the amount of memory
touched by the application. For applications with a
working set fitting in conflict-cache-size, the new policy
might be marginally slower than previous policy on platforms
having a small cache : the current policy only sets a generation
nr when an address is re-accessed, while the new policy
has to unchain and rechain the OldRef access in the LRU
doubly linked list.
2. It uses less memory (at least for big applications)
Firefox startup/exit "core" arena max use decreases from
1175MB mmap-ed/1060MB alloc-ed
to
994MB mmap-ed/913MB alloc-ed
The decrease in memory is the result of having a lot less RCEC:
The current policy let the nr of RCEC grow till the conflict
cache size is GC-ed.
The new policy limits the nr of RCEC to 133% of the RCEC
really referenced. So, we end up with a max nr of RCEC
a lot smaller with the new policy : max RCEC 191000
versus 1317000, for a total nr of discard RCEC operations
almost the same: 33M versus 32M.
Also, the current policy allocates a big temporary array
to do the GC of OldRef.
With the new policy, size of an OldRef increases because
we need 2 pointers for the LRU doubly linked list, and
we need the accessed address.
In total, the OldRef increase is limited to one Word,
as we do not need anymore the gen, and the 'magic'
for sanity check was removed (the check somewhat
becomes less needed, because an OldRef is never freed
anymore. Also, we do a new cross-check between
the ga in the OldRef and the sparseWA key).
For applications using small memory and having
a small nr of different stack traces accessing memory,
the new policy causes an increase in memory (one Word
per OldRef).
3. Functionally, the new policy gives better past information:
once the steady state is reached (i.e. the conflict cache
is full), the new policy has always --conflict-cache-size
entries of past information.
The current policy has a nr of past information varying
between --conflict-cache-size/2 and --conflict-cache-size
(so in average, 75% of conflict-cache-size).
4. The new code is a little bit smaller/simpler:
The generation based GC is replaced by a simpler LRU policy.
So, in summary, this patch should allow big applications
to use less cpu/memory, while having very little
or no impact on memory/cpu of small applications.
Note that the OldRef data structure LRU policy
is not really explicitely tested by a regtest.
Not easy at first sight to make such a test portable
between platforms/OS/compilers/....
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15119 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 06bc23a809d42c80db585b2f8ca2ea38fbe80a04 |
|
17-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix statistics about ctxt_rcec :
* the nr of discards was always 0
* the cur nr of values was shown as max
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15105 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 40648e2927dae10d81b1a1b68aad750e810c83e9 |
|
11-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove useless arguments in sparsewa, that were inheritated from WordFM
These arguments are not needed for sparsewa, as they can only
return the key given in input.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15083 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 158404e838998fbdb63ed79b175bc45e91e21998 |
|
10-Apr-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Have the event map GC use the same approach as the other GC
done from libhb_maybe_GC, i.e. check the condition in
libhb_maybe_GC, and call the (non inlined) GC only if
a GC is needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15082 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| c3508652c3a00c0d0035603a7d738f2fe47e9331 |
|
28-Mar-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Helgrind optimisation:
* do VTS pruning only if new threads were declared
very dead since the last pruning round.
* When doing pruning, use the new list of threads very dead
to do the pruning : this decreases the cost of the dichotomic search
in VTS__substract
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15044 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 900c5357f377ae0cf0dba255e660b1c2df5d93bc |
|
24-Mar-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
* Add in helgrind stats the nr of live/exit/joined/exit and joined threads
* avoid division by 0 in m_transtab.c stats before anything was done
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15037 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 4367abed70050175860cce60990fd2ab3ca805b9 |
|
28-Feb-2015 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix a few compiler warnings issued by clang 3.6.0
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14969 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 7b7d59405204f88cb944155d6bc5114025ebda98 |
|
19-Dec-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Buffer audit. Resize a few.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14824 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| b28fe8941785b44e63dfedd843e8107ee5a7cf2e |
|
28-Oct-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge revision 14309 from BUF_REMOVAL branch to trunk.
Eliminates a fixed size buffer in helgrind. Instead of building up a
string in a buffer and then writing the string to stdout can as well
write to stdout directly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14672 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 91ed8ccd3dae8a6abfaa45cc0d250df47b45187f |
|
15-Sep-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Tidy up m_xarray.c.
VG_(newXA) and VG_(cloneXA) never return NULL. Remove pointless asserts.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14539 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 6aa8bd03abedae0a3d210eaaf76b2f25775b731a |
|
15-Sep-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Tidy up m_wordfm.
First, as the allocator function does not fail, there is no need
to assert its return value.
Second, remove commented out (since r8765) function VG_(isEmptyFM).
Third, remove VG_(getNodeSizeFM) from the API. The details of the
implementation do not need to be exposed.
Fourth, for consistency require that the copy functions for keys and
values in VG_(dopyFM) (which are essentially like allocators) return
non-NULL values for non-NULL arguments if they return.
Fifth, document NULL-ness of return values for VG_(newFM), VG_(dopyFM),
and VG_(newBag). Remove pointless asserts at call sites.
Six, change avl_dopy to assert that the node the function is
supposed to copy is not NULL. It is called that way anyhow. With
that change the function never returns NULL which allows us to
simplify the call sites. Checking the return value is no longer needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14535 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| fc252b5716c04f66bcf2a72033b006e6993975ce |
|
14-Sep-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Document that VG_(newSWA) never returns NULL (because its
allocation function does not). Audit call sites.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14533 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 68790a73bcb290746a5b34c44538c3b2728eaaec |
|
13-Sep-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
VG_(malloc/calloc/strdup) never return NULL (and never will).
So it's pointless to test or assert their return values.
Remove code doing so.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14528 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 5aa09bf5e5e9ab4cd24689f80937a9268b7aaeba |
|
20-Jun-2014 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Mark unused functions as unused, to keep Clang happy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14067 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| ca903bb1b0400000f08a549f091ea193804f850c |
|
27-Apr-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
clo_processing is now done when this procedure is called.
So, we can now allocate this memory only when approx history level
is requested.
I double checked using printf that clo processing was done before
this procedure is called.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13915 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 0f157ddb404bcde7815a1c5bf2d7e41c114f3d73 |
|
18-Oct-2013 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update copyright dates (20XY-2012 ==> 20XY-2013)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13658 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 0c8a47ca278cba69e103c13a553c84aa05beffab |
|
01-Oct-2013 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove a duplicate const qualifier complained about by clang 3.3
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13597 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 195623b2e895970a6fdd8c33ba031596682d81c1 |
|
22-Jan-2013 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Make sure the variable is completely initialised. That's good
practice and also silences a complaint from the Coverity checker.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13258 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8a2bea962f5b39ee02b31426c1c4743afaca8d7d |
|
21-Jan-2013 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove pointless test. vts->ts is an array and cannot be NULL.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13256 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 6bd9dc18c043927c1196caba20a327238a179c42 |
|
23-Nov-2012 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Changes to allow compilation with -Wwrite-strings. That compiler option
is not used for testcases, just for valgrind proper.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13137 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 6bf3726ebf7a04ca48a5e6cb1ad7a3065054e54e |
|
21-Oct-2012 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix Char/HChar mixups in helgrind and then some.
Also fix all usages of the wordFM data structure. Once upon a time
wordFM used Words but now it uses UWords.
Likewise for WordBag.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13070 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 03f8d3fc25f5a45c5826259d1b33b7f310117279 |
|
05-Aug-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update copyright dates to include 2012.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12843 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 6643e96a72e8530a7c8830c02ffb2fb4aee74c88 |
|
17-Jan-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fixes 282230 group allocator for small fixed size, use it for MC_Chunk/SEc vbit
* new files include/pub_tool_groupalloc.h and coregrind/m_groupalloc.c
implementing a group allocator (based on helgrind group alloc).
* include/Makefile.am coregrind/Makefile.am : added pub_tool_groupalloc.h
and m_groupalloc.c
* helgrind/libhb_core.c : use pub_tool_groupalloc.h/m_groupalloc.c
instead of the local implementation.
* include/pub_tool_oset.h coregrind/m_oset.c : new function
allowing to create an oset that will use a pool allocator.
new function allowing to clone an oset (so as to share the pool alloc)
* memcheck/tests/unit_oset.c drd/tests/unit_bitmap.c : modified
so that it compiles with the new m_oset.c
* memcheck/mc_main.c : use group alloc for MC_Chunk
memcheck/mc_include.h : declare the MC_Chunk group alloc
* memcheck/mc_main.c : use group alloc for the nodes of the secVBitTable OSet
* include/pub_tool_hashtable.h coregrind/m_hashtable.c : pass the free node
function in the VG_(HT_destruct).
(needed as the hashtable user can allocate a node with its own alloc,
the hash table destroy must be able to free the nodes with the user
own free).
* coregrind/m_gdbserver/m_gdbserver.c : pass free function to VG_(HT_destruct)
* memcheck/mc_replace_strmem.c memcheck/mc_machine.c
memcheck/mc_malloc_wrappers.c memcheck/mc_leakcheck.c
memcheck/mc_errors.c memcheck/mc_translate.c : new include needed
due to group alloc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12341 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| ec062e8d96a361af9905b5447027819dfbfee01a |
|
23-Oct-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update all copyright dates, from 20xy-2010 to 20xy-2011.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12206 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| ffce8159a95134f0a2bc1cea3c3e6e265f096d9f |
|
24-Jun-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge the contents of the HGDEV2 branch into trunk:
* performance and scalability improvements
* show locks held by both threads in a race
* show all 4 locks involved in a lock order violation
* better delimited error messages
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11824 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 03e7d27ffe277c8e55ae689a98aee655a722af84 |
|
04-May-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
scalarts_limitations_fail_NORETURN: fix a format string error
spotted by IBM's BEAM checker. (Why didn't gcc or clang see this?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11725 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| fd35d49d5799584a7fe41d2f535c1ba2dd5e17b4 |
|
17-Mar-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
When handling client munmaps and mprotects with r=0 & w=0, actually
paint the relevant address range as NoAccess rather than ignoring the
event. This is important for avoiding VTS leaks in libhb_core.
More details in comments in the code.
Also rename the _noaccess_ painters that do nothing to make it clearer
that they do nothing :-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11654 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 0b20a15992b304fa652bb84ee4c3b63ff1eeef84 |
|
10-Mar-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Followup to r11619: more tidying up w.r.t. the renaming of
'struct _Thr :: opaque' to 'struct _Thr :: hgthread'.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11623 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 60626649e5fa6cd21af377fde5e83803fc136f61 |
|
10-Mar-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Minor cleanup (no functional change): rename 'struct _Thr :: opaque'
to 'hgthread', since that's what it is really.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11619 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 555fc57fc4c8ed646139b9e7ceaeb2857a16972c |
|
28-Feb-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Simplify the implementation of VTS__tick. The previous version was
hard to understand, and had no comments re loop invariants etc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11572 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 7aa38a97a2a49163e465a7c85b8b9469f5c7d8e2 |
|
28-Feb-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Change the representation of VTSs. Instead of using an XArray of
ScalarTSs, have the ScalarTS array as a trailing array directly on the
VTS structure. This reduces the number of malloc'd blocks per VTS
from 3 to 1, since an XArray always requires 2 malloc'd blocks. At
least for tc19_shadowmem this reduces the total amount of heap
turnover in Arena 'tool' by a factor of 3, and modestly improves
performance whilst modestly reducing overall memory use.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11571 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| e4cce74e68f351f1dd78ba7a5a412966f8d7702c |
|
24-Feb-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Scalability fix for Helgrind: reduce the size of ScalarTS (scalar
timestamps) from 16 to 8 bytes. This halves the size of vector
timestamps and reduces the amount of memory needed to run programs
that have many threads and/or many synchronisation events.
The tradeoff is that Helgrind must abort the run if the program
creates more than 2^20 (1.0e+6) threads or performs more than 2^44
(1.76e+13) synchronisation events. Neither of these seem like a
significant limitation in practice. It's easy to argue that a limit
of 2^44 synch events would take at a minimum, several CPU months on a
very fast machine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11570 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 1b9876ba9156431a687fce36959603d0fd72604f |
|
23-Feb-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
A scalability fix for Helgrind for running large workloads. When
creating new vector timestamps (VTSs) via tick and join operations,
preallocate the underlying XArray of ScalarTSs (scalar timestamps) at
the likely final size, using new function VG_(newSizedXA) introduced
in r11558. This reduces overall heap turnover (in VG_AR_TOOL) by a
factor of several. Together with revs 11567 and 11568, it mitigates
the worst-case performance falloff in long runs that involve lots of
threads and lots of synchronisation events (a.k.a Vector timestamps).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11569 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| f4845dc31a3e7a283f669ffbaa4add31d70fd6c3 |
|
28-May-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
libhb_so_recv(): don't pass a NULL filter to Filter__clear. Not sure
why thr->filter can be NULL here, though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11136 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| c8028add6294793dfc80a80d920c7dba3a89f312 |
|
05-May-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Rollup changes for Helgrind:
* Add new client request VALGRIND_HG_CLEAN_MEMORY_HEAPBLOCK. This is
like VALGRIND_HG_CLEAN_MEMORY but doesn't take an address range.
Instead it takes a single argument which is supposed to be a pointer
to the start of, or anywhere within, a heap allocated block.
Helgrind then finds the block and paints it as belonging to the
calling thread. This is needed for correctly describing the
behaviour of threadsafe reference counting when applied to classes
involving inheritance of release methods or involving multiple
inheritance.
* Add statistics counters for all basic VTS operations (tick, join,
cmpLEQ, cmp_structural).
* Rewrite VTS__cmp_structural to be much faster.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11123 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 9eecbbb9a9cbbd30b903c09a9e04d8efc20bda33 |
|
03-May-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update copyright dates to 2010.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11121 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 111544ac7149cc64bb85a0346e8b4187569579be |
|
12-Apr-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Comment-only change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11103 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 406bac81a19666c213cd8b03457a105ea33a38ea |
|
04-Mar-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Rollup fixes for Helgrind:
* tracking of barriers: add support for resizable barriers
* resync TSan-compatible client requests with latest changes
* add direct access to the client requests used in hg_intercepts.c
* add a client request pair to disable and re-enable tracking
of arbitrary address ranges
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11062 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| f585e485d4e9881fbfaac828b4c9a9a2128556be |
|
17-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Increase the maximum size of the conflict cache even more, to 30
million.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10831 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 78bb7f63a8be74e12f41d997557f371061a2bb4e |
|
14-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Double the maximum size of the conflict cache.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10817 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 5e2ac3b459ed6b1c8e6978b2ef18d73e1ad9cf14 |
|
11-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Move printing of EvM-gc and VTS-gc stats from -v to --stats=yes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10776 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 2d2ea2ff019a1c5b49b532541e30b22cae252b2d |
|
02-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Attend to space leaks, to the extent that I can.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10687 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8ab2c1303922dd85467e00cb7b5594d73b7043c6 |
|
02-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Small improvements, including some commenting, for the H1 history
mechanism.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10686 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 90eb22e2423a164cabb7a0632a8fc1d1bc8d31a4 |
|
28-Jul-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Back out a small part of r10589 (the tick-after-recv thing). On
contemplation it seems like a bad idea.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10650 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| b712617d02b247b374d1744a530f61fae1780a36 |
|
26-Jul-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Only collect stacktraces at scalar Kr boundaries at history level 1.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10621 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 23f1200ba3aa3d8dbb484626ba1bdb7cfcf3b3a9 |
|
24-Jul-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Various improvements:
* rename many functions to do with shadow memory handling, to
more clearly differentiate reads and writes directly of the
shadow state from client reads and writes, each of which
generate both a read and a write of the client state. It was
getting confusing (== hard to verify) in there.
* use idempotency of memory state machine transition rules to
speed up long sequential sections, speedups in range 0% to 28%
* remove 4-way Pord (EQ, LT, GT, UN) and associated machinery,
and replace it with something that merely computes LEQ in the
partial ordering, since that's all that is necessary, and
this simplifies some fast-case paths.
* add optional approx history mechanism a la DRD (start/end stack
of conflicting segment), much faster if you don't need exact
conflicting-access details
* libhb_so_recv: tick the VTS in the receiving thread; don't just
join with the VC in the SO. It's probably correct without this
modification, but that correctness is fragile and depends on
complex properties of how SOs are used/created. Much better to
be completely safe. (Needs cache-isation).
* get rid of unnecessary shadow memory state "SVal_NOACCESS"
and simplify associated fast-case paths in msmc{read,write}
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10589 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 24118491f347852bc311069a273fce13608dd531 |
|
15-Jul-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge helgrind/ changes from branches/MESSAGING_TIDYUP r10464.
See trunk r10465 commit message for details.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10468 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 1c0ce7a9edf8772773f6216dbad4bb04317d23b6 |
|
01-Jul-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge in branches/DCAS.
This branch adds proper support for atomic instructions, proper in the
sense that the atomicity is preserved through the compilation
pipeline, and thus in the instrumented code.
These changes track the IR changes added by vex r1901. They primarily
update the instrumentation functions in all tools to handle the
changes, with the exception of exp-ptrcheck, which needs some further
work in order to be able to run threaded code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10392 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 10522534a0273ace8c2363a0eb0a6ae59eae3241 |
|
21-May-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
When updating the constraint for a location following a race, make
sure the read-constraint <= the write-constraint. Failure to do this
leads to assertion failures later on. Fixes #181394.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10074 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 3a4b58f812bb0dd4cdb20b2869629845a683191d |
|
08-May-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix up some stack trace inconsistencies:
- When printing suppressions, never print more entries than there are in the
stack. This avoids bogus suppressions in some cases! (I haven't seen
them on Linux, but I have seen them on Darwin.)
- When getting a stack trace, stop if we get an IP of zero or one; that
means we've hit the end of the stack. And don't include that entry in the
stack trace, because it's a guaranteed "???" if it's ever printed which is
useless.
- In VG_(apply_StackTrace), we can now rely entirely on the n_ip parameter
rather than looking for 0 or -1, because that check is done when the stack
trace is first obtained. In other words, stack traces all use an n_ip
parameter to record their size, whereas previously they used an odd
mixture of n_ip and null-termination.
- Rename 'n_ips' variables as 'max_n_ips' where appropriate; those left as
'n_ips' truly describe how many IPs there are in the stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9793 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 6c83d5e38fa00ce5c1532b274b4e61834ec1db48 |
|
06-May-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Don't store the frames hash in .frames[0] and the actual frames in
.frames[1..N_FRAMES]. Instead store the hash in a separate .frames_hash
field, and the actual frames in .frames[0..N_FRAMES-1].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9778 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 4c245e595b9f6300d3120408ca873f7115d9cc7d |
|
16-Mar-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix all the non-VEX problems identified with the Clang Static Analyzer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9416 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 9f207460d70d38c46c9e81996a3dcdf90961c6db |
|
10-Mar-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Updated copyright years.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9344 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8aa41de8c586fa4e613803339fe81faca175f280 |
|
22-Jan-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Some minor format string fixes for gcc-3.3.3 (SuSE 9.1). Not sure why
later gccs don't complain about these.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9019 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 849b0ed71673805c5bdc3e44b1743a3d2c1b513d |
|
21-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Various changes:
* remove flags --trace-addr= and --trace-level=. These no longer
have any effect, so there's no point in having the associated flags.
* add flag --show-conflicts=no|yes [yes], which makes it possible to
disable the conflicting-access collection machinery. This makes
Helgrind run much faster. Perhaps useful in regression testing,
when it is desired only to find out if a race exists, but not to
collect enough information to easily diagnose it.
* add flag --conflict-cache-size= [1000000], which makes it possible
to control how much memory is used for storage of information about
historical (potentially-conflicting) accesses.
* Update comments on the conflicting-access machinery to more closely
reflect the code. Includes comments on the important aspects of
the value N_OLDREF_ACCS. Increase said constant from 3 to 5.
* Fix bug in event_map_bind: when searching for an OldRef.accs[]
entry that matches the current access, don't forget to also
compare the access sizes. The old code only compared the thread
identity and the read/writeness.
* hg_main.c: disable Dwarf3 variable/type info reading by default.
Mostly this provides little benefit and can cause Helgrind to use
a lot more time and memory at startup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8845 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 1669cc73e29e6e8f1ef0e161a9904976bc8a0e36 |
|
13-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Avoid causing an assertion failure in VG_(make_ExeContext_from_StackTrace)
in the case where VG_(clo_backtrace_size) < N_FRAMES (that is, with
--num-callers=N where N < N_FRAMES).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8820 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| a781be6728a28c94aec57f793f4d084456e93684 |
|
08-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
event_map_lookup: when looking for a previous access to an address,
find conflicting accesses that overlap the current access in any way,
rather than just match at the addresses. This allows reporting of
conflicts between accesses which overlap but are not the same
size/alignment.
Doesn't seem to always work reliably, for reasons I don't understand,
but I so far failed to make a small test case.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8811 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8f5374ee1084af8cb46ec405a1de38c5aeb9194b |
|
07-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Tidy up and comment sanity-checking code/configuration.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8810 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| c5ea9961f9705b956742ae8c553c76caa2da8c29 |
|
07-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
* In the conflicting-event mechanism, also record the size and
read-or-writeness of each access, so that these can be displayed in
error messages.
* Use recorded read-or-writeness info to avoid producing error
messages that claim claim two reads race against each other -- this
is clearly silly. For each pair of racing accesses now reported, at
least one of them will (should!) always now be a write, and (as
previously ensured) they will be from different threads.
* Lookups in the conflicting-access map is expensive, so don't do that
as soon as a race is detected. Instead wait until the update_extra
method is called.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8809 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| bc307e561793f859ead6bb1a921d6ddc9524855a |
|
06-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Use the new SparseWA data type, rather than WordFM, to implement the
(primary) mapping of the conflicting-access mechanism. This speeds
up Helgrind by 0% to 30% depending on the workload.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8807 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| d86e3a28694ca5a7c59881475b8d1f6c9ac285b0 |
|
03-Dec-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Change the memory allocation strategy used by the conflicting-access
machinery, so as to allocate fewer chunks of memory. This increases
the speed of Helgrind by about 10% on some apps, which probably means
the conflicting-access machinery itself is about 20% faster.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8803 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8fd92d394106e491df4e771f1b7e7966a550dca9 |
|
21-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
event_map_maybe_GC: use a flat array when computing the distribution
(counts) of generation numbers in the oldrefTree, instead of using a
WordFM as an associative array. This significantly accelerates the
event map garbage collector.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8794 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 3b0c4d7eedc57f8676d04aa6f9cd6c05408c448e |
|
20-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Re-set constraints in 'consistent' style after a race is detected,
instead of the more aggressive setting, which appeared to cause a
large number of extra race reports.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8793 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| b0e009d5c2607eb66d99d75683187f45db6e30db |
|
19-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Don't put raced-on locations in an (E)rror state; instead leave them
in a (C)onstraint state. The former approach can cause races to be
missed. Also, update state machine slightly following re-analysis
thereof.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8788 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 9b1f0fd7554fe79096f5e5b8043f509f534d09d4 |
|
19-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
event_map_maybe_GC: handle corner case that was previously simply
asserted on: if all the entries in the event map are in the same
generation, then we have no LRU information at all with which to
decide which entries to discard. So in this case throw away half of
them randomly -- there's nothing better we can do.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8783 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 42f17ead0cd612da2e8844aa8c8c658d39ed8e6b |
|
10-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle EvM GC messaging properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8760 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| d024ae5ca3949fa1fa9bee62825c4e0d2bda31e3 |
|
09-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update baseline expected outputs, now that Helgrind uses a different
algorithm than in 3.3.x.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8750 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| d52392dd8f0536931cb0bbf2a27f1621704f32eb |
|
08-Nov-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
A bit of tidying up:
* get rid of 'struct _EC' (a.k.a 'struct EC_') and use ExeContext
everywhere
* remove stacktrace_to_EC and call
VG_(make_ExeContext_from_StackTrace) directly
* comment out some unused code
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8749 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| 8669fd38673be80b022b5730092970fee8cf66d1 |
|
27-Oct-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Rename some local variables called 'index' to something else, to stop
gcc-3.2.2 complaining they shadow some built-in global declaration of
'index'.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8715 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|
| f98e1c03ce4bea1fb092cdea5571c41f29f6df9b |
|
25-Oct-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge Helgrind from branches/YARD into the trunk. Also includes some
minor changes to make stack unwinding on amd64-linux approximately
twice as fast as it was before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8707 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/libhb_core.c
|