The interesting part is the demangled backtrace in the error message.
Suppress the memory allocation/blocks summary which can differ slightly
depending on the underlying arch/libs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15308
Fix multipleinheritance heuristic for ppc64LE (leak_cpp_interior test).
Adjust the PPC64 #ifdiffery to indicate that ppc64BE uses a thunk table,
but ppc64LE (in particular, the ELF ABIV2) does not. In this case, thunk
table == function descriptors.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
--
This patch replaces the previously posted "[6/7] add leak_cpp_interior
test .exp results ....."
This patch fixes Vagrind bugzilla 347686
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15238
Add a suppression to handle a "Jump to the invalid address..." message
that gets generated on power. This is a variation of the existing
suppressions.
While here, I also updated the "prog:" line in the vgtest file to reference
the supp_unknown executable, versus the badjump executable. They share the
same source code, so I think this is effectively cosmetic.
This patch fixes Vagrind bugzilla 347686
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15233
Adjust the badjump2 test for ppc64le/ABIV2. Under the ABIV2 there
is no function descriptor, so the fn[] setup does not apply.
This fixes the badjump2 test failure as seen on ppc64le.
This patch fixes Vagrind bugzilla 347322.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15184
when the size is known in advance.
3 places identified where this function can be used trivially.
The result is a reduction of 'realloc' operations in core
arena, and a small reduction in ttaux arena
(it is the nr of operations that decreases, the memory usage itself
stays the same (ignoring some 'rounding' effects).
E.g. for perf/bigcode 0, we change from
core 1085742/ 216745904 totalloc-blocks/bytes, 1085733 searches
ttaux 5348/ 6732560 totalloc-blocks/bytes, 5326 searches
to
core 712666/ 190998592 totalloc-blocks/bytes, 712657 searches
ttaux 5319/ 6731808 totalloc-blocks/bytes, 5296 searches
For bz2, we switch from
core 50285/ 32383664 totalloc-blocks/bytes, 50256 searches
ttaux 670/ 245160 totalloc-blocks/bytes, 669 searches
to
core 32564/ 29971984 totalloc-blocks/bytes, 32535 searches
ttaux 605/ 243280 totalloc-blocks/bytes, 604 searches
Performance wise, on amd64, this improves memcheck performance
on perf tests by 0.0, 0.1 or 0.2 seconds depending on the test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15173
What this does is to make sure that the initial client data segment
is marked as unaddressable. This is consistent with the behaviour of
brk when the data segment is shrunk. The "freed" memory is marked
as unaddressable.
Special tweaks were needed for s390 which was returning early from
the funtion to avoid sloppy register definedness initialisation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15144
transactional memory instruction summary information. This register contains
the upper 32-bits of the transaction information. Note, the valgrind
implementation of transactional memory instructions is limited. Currently, the
contents of the TEXASRU register will always return 0. The lower 64-bits of
the trasnaction information in the TEXASR register will contain the failure
information as setup by Valgrind.
The vex commit 3143 contains the changes needed to support the TEXASRU
register on PPC64.
The support requires changing the value of MAX_REG_WRITE_SIZE in
memcheck/mc_main.c from 1696 to 1712. The change is made in this
valgrind commit.
This patch addresses Bugzilla 346474
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15134
One of the expect files was missing. Also found that there
was a bug in the stq, stqcx, lq and lqarx instructions for LE.
The VEX commit for the instruction fix was 3138.
This commit updates the expect files for the corrected instructions
and adds the missing expect files.
The bugzilla for the orginal issue of the missing instructions
is 346324.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15120
They should have been part of the previous commit 15106.
--------------------------------------------------------------------
Add support for the lbarx, lharx, stbcx and sthcs instructions.
The instructions are part of the ISA 2.06 but were not implemented
in all versions of hardware. The four instructions are all supported
in ISA 2.07. The instructions were put under the ISA 2.07 category
of supported instructions in this patch.
The VEX commit for this fix is r3137.
The bugzilla for this issue is 346324.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15107
The instructions are part of the ISA 2.06 but were not implemented
in all versions of hardware. The four instructions are all supported
in ISA 2.07. The instructions were put under the ISA 2.07 category
of supported instructions in this patch.
The VEX commit for this fix is r3137.
The bugzilla for this issue is 346324.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15106
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
Revision 14976 causes a regression : stacktrace produced when the
stack has not yet been extended to cover SP will only contain one
element, as the stack limits are considered to be the limits of
the resvn segment.
This patch fixes that, by taking Resvn/SmUpper segment into
account to properly compute the limits.
It also contains a new regtest that fails with the trunk
(only one function in the stacktrace)
and succeeds with this patch (the 2 expected functions).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15046
The function is used in VG_(client_syscall) to avoid extending the stack
when it is clear that the current value of the stack pointer does not
point into a segment that looks like a stack segment.
See the comments in the code there.
As a side effect of this we can now revert r15018 which increased
the stack size of the alternate stack in memcheck/tests/sigaltstack.c.
The reason is that the belief at the time: "alternate stack is too small"
was not correct. What instead happened was that VG_(client_syscall) called
VG_(extend_stack) without need (the syscall was tgkill) and the new stack
pointer happened to be in a file segment.
In other words: the current stack pointer was still within the alternate
stack, i.e. the alternate stack was (barely) large enough.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15034
We often get bug reports for an unhandled system call which don't
make it clear what platform is in use, which makes it impossible
to know which system call it is.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15033
This was found by accident and there is no known way to detect
an overflow of an alternate stack in the general case.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15018
memcheck/tests/Makefile.am:1: error: wrap8.stderr.exp-ppc64 is missing in EXTRA_DIST
memcheck/tests/Makefile.am:1: error: wrap8.stdout.exp-ppc64 is missing in EXTRA_DIST
memcheck/tests/Makefile.am:1: error: wrap8.stdout.exp2 is in EXTRA_DIST but doesn't exist
memcheck/tests/Makefile.am:1: error: wrap8.stderr.exp2 is in EXTRA_DIST but doesn't exist
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15015
There is special behaviout on ppc64 only. Let the filenames
reflect that. At the same time update the ppc specific
output to what it is. The important thing here is that the
stack overflow is detected. Everything else is effectively a
don't care. Should line numbers and such differ in the future
that should be filtered out.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15012
The difference of the expected results as compared to other
platforms is
- Location 0x........ is 2 bytes inside local var "budget"
- declared at varinfo6.c:3115, in frame #2 of thread 1
+ Address 0x........ is on thread 1's stack
+ in frame #2, created by BZ2_blockSort (varinfo6.c:3107)
Should the stderr output of this testcase in the future
match the generic output (varinfo6.stderr.exp) then this is
another incarnation of
https://bugs.kde.org/show_bug.cgi?id=345121
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15011
This allows to decrease memory usage when using many threads,
if no big stacksize is needed by Valgrind.
If needed (e.g. for demangling big c++ symbols), the V stacksize
can be increased.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15004
- add configure option --enable-ubsan
- add __ubsan helpers (by Julian)
This requires gcc 4.9.2 or later. Not all platforms are supported, though.
With this change and VEX r3099 regression tests pass on amd64
with a valgrind compiled with -fsanitize=undefined.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14995
bz#344560
- Also fixes memcheck/tests/badpoll test on OS X
- Problem occurs because the guest stack seen in a system call pre or post
function happens to not have a correct topmost stack frame, as Darwin system
call stubs do not start with the usual function prolog.
- New regression test case added.
- Thanks to Greg Banks for research, patch and test case.
Before:
== 587 tests, 240 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
After:
== 588 tests, 239 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14985
bz#344621
- Unnamed semaphores are not supported on OS X, must use named semaphores.
- To use named semaphores sem_open() instead of sem_init() utilised.
- Test case updated accordingly across all platforms.
Before:
== 586 tests, 240 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
After:
== 586 tests, 239 stderr failures, 22 stdout failures, 0 stderrB failures, 0 stdoutB failures, 31 post failures ==
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14968
Iop_RecipStep64Fx2, Iop_RSqrtStep64Fx2
Iop_RSqrtEst64Fx2, Iop_RecipEst64Fx2
Iop_RecpExpF64, Iop_RecpExpF32
--This line, and those below, will be ignored--
M memcheck/mc_translate.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14959
and VG_(am_get_segment_starts) to indicate which segments
should be collected. That should solve the following problem:
in m_main.c we used to:
seg_starts = VG_(get_segment_starts)( &n_seg_starts );
for (i = 0; i < n_seg_starts; i++) {
Word j, n;
NSegment const* seg
= VG_(am_find_nsegment)( seg_starts[i] );
vg_assert(seg);
if (seg->kind == SkFileC || seg->kind == SkAnonC) {
...
// ... dynamic memory allocation for valgrind
...
}
This caused the vassert(seg) to fire because the dynamic memory
allocation further down the loop changed segments such that a
valgrind segment which used to be non-SkFree suddenly became
SkFree and hence VG_(am_find_nsegment) returned NULL. Whoom.
With this revision we only collect the segments we're really
interested in. For the example above that is all client segments.
So if V allocates memory -- fine. That will not change the layout
of client segments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14949
