|Summary:||Rebase valgrind to 3.11.0|
|Product:||Red Hat Enterprise Linux 7||Reporter:||mbenitez|
|Component:||valgrind||Assignee:||Mark Wielaard <mjw>|
|Status:||CLOSED ERRATA||QA Contact:||Miloš Prchlík <mprchlik>|
|Severity:||unspecified||Docs Contact:||Robert Krátký <rkratky>|
|Version:||7.3||CC:||jakub, mcermak, mjw, mprchlik, ohudlick, rkratky|
|Fixed In Version:||valgrind-3.11.0-20.el7||Doc Type:||Rebase: Bug Fixes and Enhancements|
_valgrind_ rebased to version 3.11.0 Valgrind is an instrumentation framework that is used for debugging memory, detecting memory leaks, and profiling applications. The package has been upgraded to upstream version 3.11.0. Highlighted improvements include: * The JIT's register allocator is now significantly faster, making JIT-intensive activities, for example program startup, approximately 5% faster. * Intel AVX2 support is now more complete for 64-bit targets. On AVX2-capable hosts, the simulated CPUID will now indicate AVX2 support. * The default value for the *--smc-check* option has been changed from `stack` to `all-non-file` on targets that provide automatic D-I cache coherence. The result is to provide, by default, transparent support for JIT generated and self-modifying code on all targets. Highlighted new features in the *Memcheck* utility include: * The default value for the *--leak-check-heuristics* option has been changed from `none` to `all`. This helps to reduce the number of possibly lost blocks, in particular for C++ applications. * The default value for the *--keep-stacktraces* option has been changed from `malloc-then-free` to `malloc-and-free`. This has a small cost in memory but allows *Memcheck* to show the 3 stack traces of a dangling reference: where the block was allocated, where it was freed, and where it is accessed after being freed. * The default value for the *--partial-loads-ok* option has been changed from `no` to `yes`, to avoid false-positive errors resulting from certain vectorised loops. * A new gdb monitor command "xb [addr] [len]" shows the validity bits of `[len]` bytes at `[addr]`. The monitor command "xb" is easier to use than *get_vbits* when you need to associate byte data value with their corresponding validity bits. * The "block_list" gdb monitor command has been enhanced: it can print a range of loss records; it now accepts an optional argument, `limited [max_blocks]`, to control the number of printed blocks; if a block has been found using a heuristic, then "block_list" now shows the heuristic after the block size; the loss records/blocks to print can be limited to the blocks found via specified heuristics. * A new *--expensive-definedness-checks=yes|no* command-line option has been added. This is useful for avoiding occasional invalid uninitialized-value errors in optimized code. Beware of potential runtime degradation, as this can be up to 25%. The slowdown is highly application-specific though. The default value is `no`.
|Last Closed:||2016-11-04 02:55:33 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1297579, 1313485|
Description mbenitez 2016-01-06 21:31:28 UTC
Comment 2 Miloš Prchlík 2016-06-24 14:47:59 UTC
Verified for build valgrind-3.11.0-23.el7.
Comment 3 Robert Krátký 2016-08-19 15:42:07 UTC
Hi Mark, Could you please check the Release Notes text? Thank you.
Comment 4 Mark Wielaard 2016-08-23 11:38:40 UTC
Looks good. Two small remarks: - "to avoid false-positive errors resulting from certain of vectorised loops." I think "of" should be removed from that sentence. - It would probably be good to explicitly say "gdb monitor command" instead of just "monitor command". Then users know it is a monitor command they would use with the valgrind gdb integration.
Comment 5 Robert Krátký 2016-08-23 13:58:22 UTC
(In reply to Mark Wielaard from comment #4) Thanks Mark. > Looks good. Two small remarks: > > - "to avoid false-positive errors resulting from certain of vectorised > loops." I think "of" should be removed from that sentence. Yes, it's a typo. > - It would probably be good to explicitly say "gdb monitor command" instead > of just "monitor command". Then users know it is a monitor command they > would use with the valgrind gdb integration. Added. Thanks again.
Comment 7 errata-xmlrpc 2016-11-04 02:55:33 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2297.html