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
Changes ensures that gdbserver is called also when xml is yes.
When gdbserver is set to yes, we have to temporarily reset
xml output to no, as gdbserver output (e.g. print the last error)
has to be printed to gdb.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15031
are allocated on the stack and they can become quite large - in particular
when the client is a C++ application using the Boost library.
In combination with the demanglers recursive nature this can quickly lead
to exhaustion of valgrind's per-thread stack (which cannot be dynamically
grown). Additionally, due to the large VLAs (I've seen a 32k array) we
could run out of stack space without issuing a prior warning and instead
just segfault.
Therefore this patch allocates these arrays on the heap and frees them
later. Basically this is a respin of Joseph's r10385.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15029
This patch changes the way the transtab entries hash table is done.
Currently, the hash table is an open hash table considered full at 65%.
This means that in average, 1 entry on 3 is unused.
(all the hash table memory will be 'active' for big applications,
as the active entries are normally reasonably distributed over the hash table).
The size of a transtab entry is significant (about 150 Bytes).
To avoid having 35% of the entries unused, the translation table
is split in 2:
An hash table, that will contain an index pointing at the transtab entries.
With this technique, we are adding a small hash table,
but we spare 35% of the translation table.
Performance measurements have shown no degradation,
and some platforms have better performance. Not too clear why,
probably this helps platforms with small caches ?).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15023
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
the size of the translation table sectors, either to gain memory
or to avoid too many retranslations.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15016
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
to make it easier to obtain failing trace or unfiltered output for
tests that fail from time to time
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15014
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
of the dynamically allocated Lock addresses.
This restores helgrind/tests/locked_vs_unlocked2.stderr.exp
from r14931.
While regtesting the patch I've observed intermittent failures
of helgrind/tests/hg05_race2 like so:
--- ../../helgrind/tests/hg05_race2.stderr.exp (revision 15001)
+++ ../../helgrind/tests/hg05_race2.stderr.exp (working copy)
@@ -26,8 +26,7 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack
----------------------------------------------------------------
@@ -42,8 +41,7 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack
Surely, that's something else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15009
* common up the identical debug and clo_stat traces
* add in the stats the nr of sectors recycled
* add the avg translation size in each sector recycled
and in the final statistics
(no functional change)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15005
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
(1) In r14664 VG_(get_fnname_if_entry) was changed to always
return a function name, even if that function was *not* an
entry. That broke callgrind and was also confusing because
it contradicts what "get_fnname_if_entry" suggests.
(2) In r14189 a function call was removed because it was considered
redundant which it was not.
Both bugs were hunted down by Joseph Weidendorfer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15003
code. Previously functions exceeding that size were observed in the
field. Assert for 100x that amount.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14997
bugzilla 343597 - ppc64le: incorrect use of offseof macro fixed 3/10/2015
Issue found by Florian Krohm who also suggested the fix. The fix was
made and tested by Carl Love.
VEX commit number 3100
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14996
- 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
VG_(am_set_segment_isCH_if_SkAnonC).
Rename VG_(am_set_segment_hasT_if_client_segment) to
VG_(am_set_segment_hasT) passing in an address (because that function
cannot possible take a pointer to a *const* segment). Also assert that
the segment containing the address is a client segment. Everything else
is a bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14993
335907 segfault when running wine's ddrawex/tests/surface.c under valgrind
is assumed to be fixed either by a previous change in 3.10
and/or by the commit for 343173
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14991
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
